RIGTech

Cloud Infrastructure

Hosting, deployment pipelines and monitoring, set up so that releasing a change is uneventful and problems surface before customers find them.

What this covers

Everything between the code being written and the software being reliably available to the people who use it.

• Hosting sized to real traffic rather than to a worst case nobody has measured.
• Deployment pipelines, so a release is a command and not an evening.
• Monitoring and alerting that tells you something is wrong before a customer does.
• Backups that have actually been restored from, which is the only kind worth having.
• Access control, secrets handling and TLS set up properly rather than left at defaults.

How the work runs

We start with what you have and what it costs, because cloud bills are usually the fastest thing to improve and the easiest to justify the work with.

Infrastructure is defined in code, not clicked together in a console. That is what makes it reviewable, repeatable, and possible to recreate if a region disappears — and it is why we can hand it over without also having to hand over a person who remembers the clicks.

Changes go out the same way the software does: small, reversible, and observable while they happen.

What you have at the end

An environment you could rebuild from an empty account, and the documentation to do it.

• The infrastructure definitions, in your repository.
• A deployment process any competent engineer can follow.
• Dashboards and alerts pointed at the things that actually indicate trouble.

Who this suits

Teams whose deployments are manual, tense, or scheduled for a time when nobody is around — and businesses paying for capacity they have never measured.

Also anyone who has inherited an environment that only one person understands, which is a risk long before it is a problem.