This is the stage where you find out whether "works on the developer's machine" is different from "works for the customer". If it is, the environment has not been described, and every new release will be a gamble. For a business it looks simple: the site gets updated on Friday evening, and no orders come in until Monday.
This is the ninth stage of our app development strategy. We look at what app deployment and infrastructure setup include, what you get, what it costs and why manual releases are expensive not at release time but at the moment something breaks.
What happens at this stage
- Containerisation (Docker, docker-compose).
- Server and SSL certificate setup.
- Process automation via Supervisor.
- CI/CD pipeline setup.
The base platform is Linux and Nginx. Docker packages the application together with its environment, so the server runs exactly what was tested. Supervisor watches background processes: queues, deferred tasks, retries to external services. If a process crashes, it is restarted rather than waiting for someone to notice. CI/CD turns a release into a repeatable procedure instead of a set of commands typed by hand.
What you get at the end
- A reproducible environment that comes up with a single command.
- Configured servers, SSL certificates and their automatic renewal.
- Background processes supervised by Supervisor.
- A release pipeline: changes follow the same path from the repository to the server.
- Backups with tested restoration, not just a configured backup job.
- A rollback procedure that someone other than its author can follow.
How much deployment and infrastructure cost
In the Ingello price list the deployment and infrastructure stage costs from $800 to $4,700. It is one of only two commercial-version stages with no zero lower bound, because a minimum setup is always needed. Beyond that, the price depends on how many environments, services and recovery procedures are required:
- how many environments you need: production only, or test and demo as well;
- how many services and background processes the product runs;
- how complex the release pipeline is and which checks it includes;
- what the requirements are for backups and recovery time;
- whether we are taking over infrastructure built by another team.
The stage price is fixed before work starts and is part of the overall stage-by-stage estimate you receive after a consultation.
Manual deployment is expensive not at release time but when things break
While everything is fine, the difference between a manual and an automated release looks like twenty minutes of work. The difference shows up at night, when the previous version has to be restored quickly and the one person who knows the sequence of steps is unavailable.
That was the situation at the Prime EVA factory, where we joined a live system that was already selling and producing. We started with an audit: we went through the code, the deployment process and the database, and recorded the state of the system in a separate document. Then we automated deployment, and releasing a new version stopped being a nerve-racking manual ritual. For continuous integration we chose architectural solutions that let changes reach users in short iterations without halting sales.
Deployment as a requirement in the specification
Infrastructure is easier to commission when it is described in advance. The technical specification for the XenFit online training platform set out non-functional requirements: the system is split into loosely coupled subsystems and deploys on Ubuntu with Docker in a few steps, with separate file storage and an error log. A requirement like this can be verified: either a new team brings the system up from the instructions or it does not.
Observe rather than guess
A deployed system should report on its own state. In our promotion operations dashboard, background task timers and container health are visible on a single screen. We build the same principle into client projects: a crashed process is noticed immediately, not when a customer complains.
What the minimum includes
- A reproducible environment that comes up with a single command.
- Certificates and their automatic renewal.
- Backups with tested restoration, not just a configured backup job.
What breaks if you cut corners
- Releases depend on one person, and their holiday becomes a business risk.
- A certificate expires, browsers show a warning and buyers leave.
- A background process quietly stops, and emails to customers or order status updates stop going out.
- A backup exists, but nobody has ever restored from it, and during an outage it turns out to be incomplete.
What we need from you
- A decision on where the system will live: your own servers or hosting we select.
- The domain name and access to manage it.
- Data storage requirements, if your industry has them.
Where next
Next comes testing and handover, which also covers testing the deployment processes. The previous step: server-side business logic. The map of all stages is in the app development strategy.
If your releases are currently manual, or you inherited infrastructure from another team, let us discuss it at a free consultation with an architect. Afterwards you will receive a price and timeline estimate broken down by stage.
