A deploy pipeline that knows what Magento needs.
Generic hosting treats a Magento store as a folder of PHP. It is not — it compiles, it migrates its own schema, and it keeps state in four different places. The pipeline here is built around that.
What happens between the push and the swap.
- composer install
- setup:di:compile
- setup:static-content:deploy
On a build machine. Your store keeps serving traffic.
- upload release
- link shared media
- setup:upgrade
The new release is assembled beside the live one.
- atomic symlink swap
- reload php-fpm
- warm caches
One symlink moves. No maintenance mode, no downtime.
Build, away from production
The commit you pushed is fetched into a fresh release directory and dependencies are installed with the environment’s PHP version. A failure here ends the deployment with your site untouched — nothing has been swapped in yet.
Release, beside the live one
Shared paths — pub/media, var, env.php — are linked in, then setup:upgrade, di:compile and static-content:deploy run against the new release. The old one is still serving traffic the whole time.
Swap, atomically
A single symlink moves and php-fpm reloads. That is the entire cutover: no maintenance mode, no window where half the code is new.
Roll back deliberately
Any previous release can be restored in one click. The guard refuses to swap across PHP versions, because a release built for one runtime is not safe on another.
Provisioned, tuned and connected for you.
MySQL
Version 8.0 or 8.4 on a dedicated machine, with logical databases per environment, generated credentials, and an optional public endpoint. The buffer pool is sized to the machine and re-tuned whenever you resize it.
Valkey
A Redis-compatible node for sessions and cache, wired into env.php by the release phase. Attaching it to an environment is all the configuration there is.
OpenSearch
Catalogue search on its own node with a JVM heap matched to the machine size. Shared between environments when you want it, isolated when you do not.
Media volumes
pub/media lives on a block volume mounted into every release, so images survive deploys and rollbacks alike. Grow it when the catalogue grows.
The store after it is live.
Running a shop is mostly the weeks between deploys — reindexing, flushing caches, restoring a database, checking why a page got slow.
Domains and certificates
Add a hostname, point the DNS record, and the certificate is issued and renewed automatically. Verification state and failures are visible instead of silent.
Backups, restores and imports
Databases are backed up nightly and kept for a week. Download one, restore it into an environment, or import a dump from your current host.
Metrics and logs
CPU, memory, disk and network for every machine, alongside deployment logs and application logs, without opening a terminal.
Commands and SSH
Run bin/magento commands from the dashboard and watch the output stream, or connect over SSH with your own key.
Push to deploy
GitHub and GitLab connect over OAuth. Pushes to the tracked branch deploy automatically; deploy hooks cover everything else.
Notifications
Failed deployments, failed backups and payment problems arrive by email and in the dashboard, so you are not the last to know.
One page that answers whether everything is still up.
Failed deploys, stopped environments, domains that did not verify and backups that did not run are surfaced first — above the deploy history and what the month is costing so far.
The whole build, streamed while it runs.
Output arrives as it happens rather than at the end, so a build that hangs on composer is obvious immediately — and a failure tells you which phase it died in.
See what it costs before you sign up.
The whole price list is on one page, with two worked examples and the per-hour rates behind them.