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 box holds app + DB + storage. Fits a program up to a few hundred concurrent authors. Install: signed bundle + 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 carries the application, its Python virtualenv contents, the UI build, the SDM packages, and the bundled publishing backends (WeasyPrint, Apache FOP, ironmarkpdf). 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.
Ironmark runs comfortably on a small VM for evaluation (2 vCPU / 4 GB / 40 GB disk). Production sizing depends on concurrent authors, PDF generation load, and how much graphics storage a program carries. For most single-program installs, 4-8 vCPU / 16 GB is the working range. Publish load is the primary driver — scheduled PDF runs are the heaviest 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 is deliberate. Split code paths inevitably diverge over time. By treating the most restrictive deployment model as the default, every release is built, tested, and maintained for environments that cannot depend on external services. If it works there, it works everywhere else.