Home → Architecture → Deployment
Ironmark ships as a self-hosted platform. One tier — one binary bundle, one database, one deployment path. Same code runs the demo instances at ironmark-authoring.com, the customer's on-prem servers, and airgapped installs behind program firewalls.
| Self-hosted single-node | The default. One VM or bare-metal host holds the application, database, and storage. Capacity depends on the authoring workload, document set, graphics volume, and publishing activity. Install with the supplied bundle and install.sh. |
| Airgap | Same install path as connected self-hosted; the bundle carries every dependency inside it. Updates delivered as signed bundles copied across the airgap boundary and applied through the admin panel. See the airgap deployment page. |
| Cloud-hosted demo | How trial and evaluation instances run. Ironmark spins each demo on a fresh VM with sample data seeded. Same code as self-hosted; the difference is who runs the VM. |
| Multi-instance | A large customer may run several instances (dev / staging / prod, or one per program). Each instance is standalone — no cross-instance content sharing. TM Families operate within a single instance. |
The signed bundle includes the application, its Python virtual environment, the UI build, the SDM packages, and the in-box publishing backends (WeasyPrint and ironmarkpdf). Apache FOP is an optional external engine — install.sh offers it during installation, or the operator can install it beforehand. install.sh validates the signature, extracts, migrates the database (via Alembic), and starts systemd units. First-boot creates the admin user and issues a startup credential the operator uses to sign in.
install.sh in upgrade-mode. Same steps as the admin-panel path, wired to a shell.Ironmark is designed to support standard enterprise backup and disaster recovery practices. Regular, tested backups of the application, database, file storage, and published deliverables are essential. If you cannot restore your data from backup, you should assume you do not have recoverable data.
Ironmark's data lives in two places: the MySQL database and the filesystem storage tree (content, graphics, publish outputs, bundles). Any backup strategy covering both — nightly mysqldump + rsync of the storage tree, or filesystem snapshots — is compatible. Restore is: install the bundle → restore DB dump → restore storage tree → start service.
Evaluation instances can begin on a modest VM. Production sizing depends on concurrent activity, document volume, graphics storage, integrations, backup policy, and PDF generation load. Ironmark does not publish an unqualified concurrency or production-capacity figure; sizing is established against the customer's expected workload.
The air-gapped deployment and the hosted demonstration environment run the same application bundle. There is no separate "air-gap edition" that lags behind a connected build.
This avoids a separate airgap product line. Each customer still validates the bundle, operating-system dependencies, certificates, and integration configuration required by its environment.