Service3 of 6
Cloud and DevOps
We set up, automate and document the infrastructure your platform runs on. Your team can ship and recover it without depending on us.
- Category
- Cloud and DevOpsVerified
- Detailed capabilities
- Pending verification
- Engagement models
- Fixed-scope project
- Maintenance and operations retainer
- Block of hours
- Handover record
- Repository · Documentation · Access · Infrastructure in your name
From a change to production
Illustrative diagram. It does not represent any client’s architecture.
- Code
- Integration
- Artifact
- EnvironmentsStagingPrevious versionProductionPrevious version
- Observability
What is observed feeds back into the code
Every state
Release: Change
A reviewed change is merged into the main branch.
- What is recorded
- The approved review and the repository history.
- Running
- Staging: Previous version. Production: Previous version.
Release: Checks
Tests, analysis and the build run on every change. If one fails, the change goes no further.
- Integration
- Automated tests and checks on every change.
- What is recorded
- The result of each check, linked to the change.
- Running
- Staging: Previous version. Production: Previous version.
Release: Artifact
A versioned package is built once. It is the same one that goes to every environment.
- What is recorded
- The artifact version and the change it comes from.
- Running
- Staging: Previous version. Production: Previous version.
Release: Staging
The artifact is deployed to staging and verified there.
- Environments
- Staging and production with the same procedure.
- What is recorded
- Who deployed, which version and the result of the verification.
- Running
- Staging: New version. Production: Previous version.
Release: Production
The same artifact is promoted to production. The previous version stays ready to return to.
- Environments
- Staging and production with the same procedure.
- What is recorded
- The promotion, with the version it replaces.
- Running
- Staging: New version. Production: New version.
Simulate a failure: Detect
Metrics cross the agreed threshold and an alert fires, before anyone complains.
- Observability
- Logs, metrics and alerts to know what is happening.
- What is recorded
- The alert, the metric that triggered it and who it notified.
- Running
- Staging: New version. Production: New version.
Simulate a failure: Roll back
Production goes back to the previous artifact with the same procedure. Nothing is rebuilt.
- Environments
- Staging and production with the same procedure.
- What is recorded
- The rollback, who did it and to which version.
- Running
- Staging: New version. Production: Previous version.
Simulate a failure: Write up
The runbook records what happened, how it was detected and how it was rolled back. The fix comes in as a new change.
- What is recorded
- The runbook entry, linked to the alert and to the change that fixes it.
- Running
- Staging: New version. Production: Previous version.
Related scope: Cloud deploymentCI/CD pipelinesContainersMonitoringOperational documentation
What it solves
Common situations, not client cases.
- P-01
Your deployments depend on manual steps that only one person knows.
What changesAn automated, documented procedure that anyone on your team can run.
- P-02
You find out something is failing in production when someone complains.
What changesLogs, metrics and alerts defined so you find out sooner.
- P-03
Nobody on your team knows for sure how to bring the system back if something breaks.
What changesRunbooks and deployment documentation, delivered with the work.
What’s included and what isn’t
Included
Environments prepared on the provider you choose or already use, with the configuration documented.
Automated integration and deployment: every change is tested and released with the same procedure.
Applications packaged so they run the same way in every environment.
A reasoned choice between managed functions and containers, based on the workload and the team that will maintain it.
Basic logs, metrics and alerts, defined together with your team.
How it is deployed, how it is recovered and who has access to what.
Not included
Proposal pending approval- EX-01
Ongoing Kubernetes cluster management
Not offered as a managed service.
- EX-02
Multi-cloud infrastructure as code
Not offered as a specialty.
- EX-03
Specialized cloud cost optimization
No dedicated FinOps practice.
- EX-04
Payment for cloud provider services
Accounts and their billing stay in your company’s name.
- EX-05
Guaranteed response times
Support commitments are set in the contract, not on this site.
Boundaries proposed for review (A-07). They are not approved exclusions.
What you receive at the end
This is what you receive. Each row shows whether it passes to you, depends on the contract or is not transferred.
KorhyYour company
- Passes to you
- Per contract and model
- Not transferred
Final ownership is set by each project’s contract.
Base · in every service
- EN-01
Repository
The source code and its history, in a repository your company owns.
Passes to you
- EN-02
Documentation
How the system is built, why it was built that way and how to get it running.
Passes to you
- EN-03
Access
Admin credentials and permissions, handed to the people you name.
Passes to you
- EN-04
Infrastructure in your name
Cloud provider accounts in your company’s name. The exact arrangement is set by the contract.
Per contract and model
Specific to Cloud and DevOps
- EN-05
Documented CI/CD pipeline
The pipeline definition in your repository and a guide to changing it.
Passes to you
- EN-06
Operational runbook
What to do in foreseeable incidents, step by step.
Passes to you
- EN-07
Deployment documentation
How a version is released and how to roll back to the previous one.
Passes to you
What is not transferred
Proposal pending approval- NT-01
Our own tools from before the project
Internal accelerators we already had. You use them under a licence; they are not assigned.
Licensed for use per contract
- NT-02
Licensed third-party technology
Services and software from other vendors that the solution uses.
Subject to the vendor’s licence
Engagement models
We don’t publish prices: they depend on the scope. Response times, where they apply, are set in the contract.
| Criterion | AFixed-scope projectSelectedRemove: Fixed-scope project | BMaintenance and operations retainerEnquire with this model: Maintenance and operations retainer | CBlock of hoursEnquire with this model: Block of hours |
|---|---|---|---|
| When it applies | When you need to set up or migrate an environment with a clear goal and clear limits. | When the platform is already in production and needs ongoing care. | When the work is occasional or variable: a review, a pipeline adjustment, a small migration. |
| How it works | We agree on scope, schedule and price before starting. Scope changes are reviewed in writing. | A monthly fee covers an agreed set of operations and improvement tasks. | Prepaid hours used task by task, with a log of what was done. |
| Deliverables | Deployed environment, documented pipeline and a handover record at the close. | A periodic operations report and an up-to-date runbook. | Hours log and the documentation for each task. |
| Contract considerations | The price is set in the proposal. Cloud provider services are billed separately. | The monthly scope and the SLA are agreed in writing in the contract. | How long the hours stay valid, and on what terms, per the contract. |
- A
Fixed-scope project
- When it applies
- When you need to set up or migrate an environment with a clear goal and clear limits.
- How it works
- We agree on scope, schedule and price before starting. Scope changes are reviewed in writing.
- Deliverables
- Deployed environment, documented pipeline and a handover record at the close.
- Contract considerations
- The price is set in the proposal. Cloud provider services are billed separately.
- B
Maintenance and operations retainer
- When it applies
- When the platform is already in production and needs ongoing care.
- How it works
- A monthly fee covers an agreed set of operations and improvement tasks.
- Deliverables
- A periodic operations report and an up-to-date runbook.
- Contract considerations
- The monthly scope and the SLA are agreed in writing in the contract.
- C
Block of hours
- When it applies
- When the work is occasional or variable: a review, a pipeline adjustment, a small migration.
- How it works
- Prepaid hours used task by task, with a log of what was done.
- Deliverables
- Hours log and the documentation for each task.
- Contract considerations
- How long the hours stay valid, and on what terms, per the contract.
05Questions
Frequently asked questions
What people ask us most before starting.
We start with a diagnosis of the current environment and what you need to achieve. From that we write a proposal stating what is in, what is out and how changes are reviewed.
It depends on the scope. After the diagnosis we send you a proposal with the scope, timeline and cost. If you go ahead with the project, the diagnosis fee is credited against the proposal.
In your company’s name, from the start. The exact ownership and access terms are set in each project’s contract.
What your team needs to run the system without us. It is written during the project, not at the end, and kept in your repository next to the code, so it changes with it.
- Technical documentation: architecture and decisions made.
- Deployment documentation: how a version is released and rolled back.
- Operational runbook: what to do in foreseeable incidents.
- Access inventory: who has access to what and how it is revoked.
The format (Markdown in the repository, an internal wiki or something else) is agreed at the start, based on the tools your team already uses.
Yes, through a maintenance and operations retainer or a block of hours. The scope and any support commitment are defined in the contract.
Cloud provider services, licences and other third-party tools are contracted in your company’s name and billed separately. The proposal lists them before work starts.
If we use our own tools that existed before the project, they are not transferred: you get a licence to use them on the terms of the contract. What we build for you follows the agreed assignment terms.
Your enquiry
This comes with you to the contact form. The link only carries the service and the model.
- Service
- Cloud and DevOps
- Model
- Fixed-scope projectRemove or change the model