Deployment is the beginning of the lifecycle.
Infrastructure is only useful when it can be maintained, updated, recovered, and handed over. Operations is the recurring work that keeps a launched system healthy.
What that work includes, and who is responsible for each part, is defined by the agreed operating model — not improvised after the first incident.
Four responsibilities, kept distinct
These responsibilities are named separately because they are scoped and contracted differently. Not every engagement includes all four.
- Infrastructure hosting: operating the servers and environments a platform runs on. If AstraNET does not host infrastructure directly, it can operate software on customer-selected infrastructure.
- Application and platform management: keeping the deployed software current, configured, and observable, including its dependencies.
- Support: a defined contact for operational questions, changes, and escalations during agreed hours.
- Incident response: a documented process for reacting to failures and security events, with agreed follow-up.
Scoping responsibilities
The responsibilities below are questions to resolve in an agreed operating model, not fixed service packages.
- Deployment: who installs the system and who takes over afterwards?
- Handover: what documentation and access does your team need?
- Maintenance: who handles updates, monitoring, and recovery?
- Operations: who responds to incidents under the agreed service model?
What operations can include
The concrete scope is agreed per engagement and system; not every item applies everywhere.
Maintenance windows
Planned and communicated windows for work that affects availability or users.
Upgrades
Version upgrades with testing before rollout and a planned rollback path.
Security patches
Agree on prioritization, testing and rollout responsibilities for security updates.
Monitoring
Checking availability, resource use, and application health — not only host uptime.
Alert handling
Defined routing for alerts so that a failure reaches someone who can act.
Backup verification
Define whether backups are configured, who checks them and how their integrity is verified.
Restore testing
Agree on restore procedures and whether and when they will be tested.
Dependency maintenance
Tracking and updating the libraries and components the platform depends on.
Capacity reviews
Periodic reviews of capacity and growth so scaling decisions stay planned.
Documentation updates
Keeping runbooks, configuration records, and recovery documentation current.
Discuss your operating model
Tell us which systems need to stay healthy, who operates them today, and what support you expect after handover.