Why Inertia
Own your delivery pipeline
One control plane for the whole path from commit to production, running where your software runs.
No per-minute CI bills
Builds run on machines you already own. A long test suite costs you nothing extra per minute.
Code and secrets stay with you
Repositories are checked out on your agents; secrets are sealed in your database and redacted from every log.
Controlled path to production
Releases move through ordered environments with approvals, freezes, health checks and automatic rollback.
One place for everything
Builds, releases, deployments, agents, insights and the audit log in a single interface.
How it fits together
A control plane, agents, and your servers
The control plane decides what should happen. Agents on your machines do the work and report back. Nothing needs to connect inward to the machines you deploy to.
Control plane
Web interface, REST API, orchestration and live logs. State in PostgreSQL, logs and artifacts in S3-compatible storage.
Agents
Small services on your machines. They enrol once with a single-use token and connect outward over mutual TLS.
Your servers
Build machines with Docker, and the hosts you deploy to: containers, systemd services, static sites and more.
Agents dial out to one agent port on the control plane, so target machines need no open inbound ports.
Product tour
See it on screen
Real Inertia screens, with fictional projects and people.
What runs where: the release in each environment of every project, whether it is healthy, and what needs attention.
From commit to production
How a change reaches production
The same, recorded path for every project.
Build
In a container on your builder, with live logs
Release
Artifacts, variables and process frozen
Test
Deployed automatically if you choose
Staging
Promoted with a preview of the exact targets
Approval
Someone other than the requester decides
Production
Deployed step by step, then health-checked
Rollback
Automatic on failure, or one click
Builds
Builds on your machines, in containers
A builder agent runs each step in the container image you name, so any language or toolchain that runs in a container builds here.
- Build the default branch, any branch or an exact commit
- Step-by-step live logs, coloured output and cancellation
- Docker images pushed to your own registry, archives and static bundles kept as artifacts
- Private repositories checked out with a per-project token, over HTTPS only
- Builders clean up the images they build and sweep their cache
Releases & environments
Immutable releases, ordered environments
Every release is a fixed snapshot. What you tested in staging is exactly what reaches production.
- Releases made automatically from the default branch, from listed branches or by hand
- Ordered environments such as test → staging → production, shared by every project
- Automatic deployment per environment — never straight into production from a feature branch
- Keep the last N releases on each target, from 2 to 20
- Compare a release's frozen variables with the current definitions
Approvals, freezes & rollback
Safe by default in production
An environment marked as production needs approval unless a project says otherwise — and nobody approves their own deployment.
- Approvers named as users or teams, with a required number of approvals
- A confirmation that names the exact targets and every reason a deployment would be refused
- Freeze an environment with a reason; new deployments, automatic ones and rollbacks included, are refused until it is lifted
- Health checks per step, with custom request headers
- Automatic rollback to the last good release — never past a database migration
Agent fleet
Your build and deploy machines in one view
Each agent reports its version, platform, health and what Inertia deployed on it, once a minute.
- Enrol a machine with a single-use token that expires within an hour
- CPU, memory and disk charts for the last hour, day and week, with warnings
- Drain an agent to stop new work; restart it or rotate its certificate from the interface
- A closed set of recorded operations: restart a service, re-run a health check, prune old releases, tail a log
- Agents update themselves to signed releases, rolled out in waves with production last
Insights
Delivery measured with evidence
The four delivery metrics every engineering team talks about, computed from your own builds, releases and deployments.
- Deployment frequency and lead time from commit to production
- Change failure rate and time to restore
- Per project and per environment, in your own time zone
- Build and deployment durations, and which step fails most
- Every chart with a “show the numbers” table beside it
Where it deploys
Typed deployment steps, not free-form scripts
A deployment is a sequence of named steps run by the agents in an environment. Each step type knows how to place, start, check and roll back what it deploys.
Docker containers
The new container starts beside the old one; traffic switches once it is healthy.
systemd services
A service under a unit Inertia writes; if the new release fails its health check, the previous one is put back.
Static sites
A static bundle in a release directory behind a managed Caddy or your own proxy.
Database migrations
Flyway, Alembic or an EF Core bundle, with a guard on deploying back past a migration.
Configuration files
Templates rendered on the target from the release's variables.
HTTP checks
A URL asked until it answers as expected, with retries and backoff.
Windows targets
IIS sites and Windows services, from a Windows agent.
Notifications
A message to a channel in the middle of a deployment.
Step templates let an administrator publish a few steps once, as a numbered version, and every project use them by name.
Security & control
Built for teams that answer for their releases
Who may deploy where, which secrets a step sees, and what changed — all explicit and all recorded.
Variables by project, environment and role. Secret values are sealed and never shown again — not in the interface, not in logs.
Self-hosted
The control plane, its database and its storage run on your infrastructure.
Mutual TLS agents
Each agent has its own key and a certificate from your installation's own authority.
Roles and teams
admin, project_admin, deployer, approver and viewer, at global, project or environment scope.
Two-factor sign-in
An authenticator-app code at sign-in, its secret sealed in the database.
Sealed secrets
Encrypted under your master key, never returned by the API, redacted from build and deploy logs.
Four-eyes approvals
The person who asks for a production deployment can never approve it.
Audit log
Every write is recorded with who, when, from where and which fields changed.
Signed agent updates
Agent releases are signed offline; the control plane can serve them but cannot sign them.
Running Inertia
Simple to install, built to be operated
Inertia is one server binary under systemd, behind your TLS proxy, next to services you already know how to run.
What it needs
- A Linux host with systemd
- PostgreSQL 17 or later
- S3-compatible object storage
- A container registry, if you build images
- A TLS reverse proxy and one inbound port for agents
What comes with it
Setup wizard
A one-time setup code, the first administrator, connection checks and the first agent.
Health and metrics
/healthz, /readyz and a Prometheus /metrics endpoint.
Backup and restore
Built-in commands, with the restore rehearsed in the product's own test suite.
Notifications
Email, Slack and signed webhooks for failures, approvals waiting, agents offline and freezes.
Registry retention
Keeps only the images a target may still need.
Managed reverse proxy
Let Inertia's managed Caddy serve a project and renew its certificates.
We use it ourselves
Avva Mobile builds Inertia and ships its own services with it. We can install it on your servers, connect your first projects and stay with your team while you move over.
- Installation on your infrastructure
- Onboarding of your first projects
- Support while your team settles in
Frequently asked questions
Inertia is a self-hosted CI/CD and deployment platform developed by Avva Mobile. It builds your code on your own agents, turns successful builds into immutable releases and deploys them through ordered environments with approvals, freezes and automatic rollback.
A Linux server with systemd, PostgreSQL 17 or later, S3-compatible object storage, a container registry if your pipelines build images, and a TLS reverse proxy with one inbound port for the agents. Builder machines need Docker.
Each build step runs in a container image you choose, so anything that builds in a container builds in Inertia — for example .NET, Node.js, Java, Go or Python. A build can produce a Docker image, an archive or a static site bundle.
An agent is enrolled once with a single-use token. It creates its own key, receives a certificate from your installation and from then on connects outward to the control plane over mutual TLS. The machines you deploy to need no inbound ports.
Rolling back is deploying an earlier release, which is a frozen snapshot. A deployment can roll back automatically to the last release that succeeded in that environment when it fails. Inertia never reverses a database: going back past a migration needs an explicit acknowledgement, and an automatic rollback never does it.
There is no automatic importer. A pipeline is one YAML file and build steps are ordinary commands in containers, so existing build scripts usually carry over. We recommend starting with one or two pilot projects while the old process keeps running, and we can plan the move with you.
No. Repositories are checked out on your own agents, and secrets are sealed in your own database, never shown again and redacted from logs.
There is no public price list. The scope of installation and support is agreed with you and a quote follows a demo. Builds run on your own machines, so there are no per-minute build charges.
Ready to run your pipeline on your own terms?
Let's look at Inertia together, with your projects in mind.
