Services / Software house support
Software houseWe design and operate a DevOps platform under your clients' projects
We design, deploy, and operate a delivery platform under your clients' projects. We start from how the team delivers: repositories, environments, secrets, and who deploys to which client. Then we stand up a pipeline template, isolated environments, and Argo CD. We stay for on-call, SLO, and a report you can write into the client contract.
How it fits together
From the delivery method to tenants and on-call
First we understand how the team delivers. On that basis we put together CI, GitOps, isolation, and observability. GitLab, GitHub Actions, Argo CD, and Grafana are what we use for that work every day. We hold the infrastructure under the product. The product backlog stays with you.
- A retainer or per-project model, with a clear split of who takes application P1.
- Showback per project sits next to SLO, so cost and care have the same owner.
We build a pipeline template the team copies onto a new project
One harness: test, scan, image, preview. A new client starts from that template. Runner and registry are yours or ours, with isolation and cost per project.
Template
Repo starter, environments, secrets, branch policy.
Preview
The merge request comes up in an isolated space and disappears. The client sees a build from that environment.
Scan
Dependencies and image in the pipeline. A finding goes to the project backlog.
Billing
CI minutes and registry can be assigned to a client.
We operate GitHub Actions when the team already works there
The same level of gates and OIDC to the cloud. A workflow per template. We size Actions to what the team will maintain, from the kubernetes/kubernetes pattern down to your scale.
OIDC
A short-lived role per environment. No long-lived key in secrets.
Matrix
Client A does not see client B secrets. Separate environment protections.
Cache
Faster build, with artifacts kept apart between tenants.
Audit trail
Who approved a deploy to the client production.
We stand up an environment per client, with a separate project
ApplicationSet or a project template. Namespace, quota, network. The client sits in a scoped project. Sync and health are visible on the dashboard, with an owner.
Isolation
RBAC, NetworkPolicy, separate secrets. Blast radius of one project.
Template
A new environment from a merge, from the same catalog as the last client.
Promotion
Client staging, then production. The same path as inside your organization.
Offboarding
Data retention and namespace deletion are in the contract checklist.
We operate on-call and SLO you can put in a contract
A dashboard per tenant or folder. The alert comes to us, with escalation to you when it is the application. An availability report for the contract. Night coverage sits in the retainer.
SLO
p95 and error per client service. Budget written down.
On-call
P1 on infrastructure. P2 on the application per the contract.
Cost
Showback per project. The client sees what they pay in the cloud.
Handover
When the project leaves, documentation and IaC remain, with the runbooks next to the repo.
How we work
From the client projects to a platform
We start from your delivery method. Then we stand up an environment catalog. We onboard the first client on the template. We stay for on-call, showback, and offboarding.
- Template We put together pipeline, chart, secrets, network, and quota. That is the catalog for the next client.
- Onboarding We onboard the first client on the template, with isolation and billing.
- Rhythm We run platform upgrade, scan, and a tenant review.
- Contract We write SLA, escalation, offboarding, and a report you can put into the client agreement.
Talk
We will discuss the environment template and SLA
On that basis we will prepare a scope: platform, isolation, and on-call.
Contact us