Deploy day used to be panic day?
Most engineering teams know the feeling. The release window approaches and the calendar fills with backup plans. Someone stays late "just in case." The week after the deploy is recovery, not progress. It does not have to be this way.
A one-hour session with one of our engineers identifies what makes deployment an event in your current stack, and outlines the work required to make it routine. You receive a written report. It stays yours, regardless of the next step.
A written report, yours.
One hour with one of our engineers, followed by a written report covering current architecture, the actual constraint, and a realistic timeline.
Automatic rollback by design.
New application versions are brought up gradually and validated by health checks before old ones are removed. The rollout reverts on its own when something deviates.
No vendor lock-in.
Standard upstream Kubernetes, no proprietary fork. The cluster, the documentation, and the operational knowledge belong to your team after delivery.
The deployment problem,
named precisely.
In most engineering organisations, deployment is still an event.
It has a time slot. It has a designated operator. It has a rollback plan that often reduces to reverting manually and hoping the database holds. And it carries a tacit consequence: teams that ship in this mode ship less often than they would like to. Every release becomes a negotiation with operational risk. Releases accumulate. Features wait. Technical debt grows.
The cost is rarely visible on a single budget line. It is distributed across slower release cadence, longer recovery times after incidents, weekend deploys, customer-facing maintenance windows, and the cognitive load of an engineering team that treats every release as a potential outage.
There is an architectural configuration that removes the event entirely. New application versions are introduced into production progressively, validated by automated health checks, and reverted by the system itself when any check fails. The technology exists. The implementation has three prerequisites. Identifying whether your current infrastructure meets them is the work of one focused session.
What changes when deployment
stops being an event.
Release frequency goes up.
When each deploy costs less attention, teams ship more often. The bottleneck moves from operational risk to actual product decisions.
Mean time to recovery drops to minutes.
Rollback is automatic. The system reverts before most of your users notice the deviation, and before anyone on the team is paged.
Maintenance windows disappear.
Customers stop receiving downtime announcements. Internal communication about releases shifts from coordination to information.
Engineering attention reallocates.
Weekend deploys and 3 AM rollbacks stop being part of the job. The hours return to product work, architecture, and the things that compound.
Deployments that fix themselves.
Most production releases still require a scheduled window, a designated operator, and a manual rollback plan. They don't have to. The architectural pattern that removes the event entirely is real, deployable, and already running in production at companies of every size.
The question is not whether it works. The question is whether your current stack can host it. That is what the assessment determines.
The mechanism,
in plain terms.
The principle is simple. When you deploy a new version, new instances of your application come up alongside the old ones. Each new instance is validated by health checks before it receives any real traffic. Old instances are removed only after the new ones have proven they work. If any health check fails during the process, the rollout stops and reverts on its own. The old version is still running, untouched, ready to take back the load.
Whether this is viable in your infrastructure depends on three prerequisites.
Container-based orchestration.
A system capable of running two application versions in parallel and routing traffic between them programmatically. Kubernetes is the de facto standard, but the pattern exists independently of the technology.
A pipeline that can deploy automatically on signal.
Your CI/CD must be able to push a new version into production without manual intervention, and to read the same health signals that the deployment system reacts to. Many pipelines today deploy on a button click, not on a signal. The two are not the same.
Database schema compatible with two application versions running simultaneously.
The constraint most assessments overlook. A poorly designed schema migration makes safe deployment impossible, regardless of how mature the rest of the stack is. It is also why so many implementations stall halfway through: the infrastructure is ready, the data isn't.
When the three are aligned, the result is the configuration described above. When one is missing, the assessment identifies which one, and the path to address it.
One hour. One engineer.
One written report.
A working session, structured around your stack.
One hour with one of our engineers. Remote, scheduled within 72 hours of request. Paid engagement, billed independently of any work that may or may not follow.
The full deployment chain, end to end.
Your current deployment process. The infrastructure underneath it. The database migration patterns in use. The CI/CD pipeline and its observability layer. The team structure operating it.
A written report, with a clear recommendation.
Current architecture, the specific constraint that turns deployment into an event today, the work required to remove it, a realistic timeline, and an indication of effort. If the right answer is to leave things as they are, the report says so.
The report belongs to you.
Use it internally, share it with your CTO, share it with another vendor. There is no obligation to proceed with Graftholders. The assessment is paid; the analysis is yours to keep regardless of the next step.
Why this works
as a written report.
Most infrastructure proposals come from vendors selling a fixed solution and adapting the diagnosis to fit it. Our model is the opposite: the diagnosis is the product. The intervention, if any, follows.
A written report does three things a conversation cannot. It survives the meeting. It can be circulated internally to people who weren't in the room. And it commits the analysis to writing, which is the only form in which technical recommendations can be evaluated rigorously.
The session is paid for a reason: it filters both sides. We commit a focused hour and a written deliverable to every case, which means we only run assessments where the case actually warrants one. In a meaningful portion of them, the conclusion is that the current infrastructure is the right fit and no migration is recommended. We say so, in writing.
The report is yours. Whether you proceed with Graftholders, with another vendor, or with no vendor at all, the analysis travels with you.
Engagement by stage.
Every engagement starts with the assessment. Everything that follows is optional, activated only when your case requires it.
Assessment
Diagnosis before design. Constraints, workload, and goals mapped in a written report. The outcome is a clear recommendation, including the option of not adopting Kubernetes at all when that is the right answer.
Cluster Setup
Production-ready cluster, fixed delivery. Full configuration with integrated GitOps pipeline. Works across European bare metal, European cloud, US hyperscalers, and on-premise data centers. Documentation included. Fixed fee, three tiers: Small, Medium, Complex.
GitOps Training
One to two days. The team becomes autonomous. Designed for cases where the client's team needs to operate the cluster in full independence. On-site or remote. Per-edition pricing, independent of headcount up to a defined cap.
Maintenance Pack
Prepaid days, used on demand. For clients who want ongoing coverage without a monthly retainer. Updates, troubleshooting, optimization, spot penetration testing. Packs of 5, 10, or 20 days, twelve-month validity.
Optional
Stack details
Applications installed through GitOps. Standard CNCF and open-source components. No proprietary forks. Configured during cluster setup, declared in version control, deployed and updated through GitOps.
Standard CNCF and open-source components. No proprietary forks. Configured during cluster setup, declared in version control, deployed and updated through GitOps.
Where are you?
2 minutes to understand if Kubernetes makes sense for your case right now.
Four client profiles.
Three project stages.
Different starting points, the same methodology. Select where you are today.
You think Kubernetes is overkill for where you are now?
For early-stage startups that don't yet know what they need, a full Kubernetes cluster can feel out of reach. We build a simple, working prototype that lets you ship and scale without committing to infrastructure you don't need yet. This is one of our most requested services.
Early-stage product in production
Early-stage company with an MVP in production. Limited budget, no dedicated DevOps. Cloud costs already a concern.
Cluster on low-cost European cloud
Production-ready Kubernetes cluster with integrated GitOps pipeline. Optional application development on top of the cluster.
Predictable European infrastructure
Engineering team aligned on the cluster from delivery. Maintenance available on demand if required.
Regulatory or geographic constraints
Data-residency, latency, or sector-specific compliance requirements (healthcare, finance, public sector). Hyperscaler defaults do not fit.
Bare metal cluster, constraint-driven
Kubernetes cluster on European bare metal. Architecture designed around regulatory and geographic constraints. Integrated GitOps pipeline.
Infrastructure built for your constraints
Built for the client's constraints, not for the provider's catalog. Predictable costs.
Established team, stable workload
Significant in-house development team. Stable workload, governance requirements, long-term infrastructure ownership.
Workload-matched architecture
Kubernetes cluster on European bare metal with architecture matched to actual workload patterns. GitOps as operational methodology. Optional retainer.
Governed by your team
Infrastructure governed by the client's team, not by an external vendor. A partner available on demand.
Multi-region complexity
Multi-region operations, varied latency requirements, differing regulatory environments, distributed engineering teams.
Multi-region, compliance integrated
Multi-region Kubernetes architecture on European bare metal. Compliance integrated by design (IEC 62443, CRA, NIS2, GDPR). Cross-region GitOps.
Single point of contact
Compliance built in from day one, not retrofitted. One interlocutor across the full delivery chain.
Your product can't run on Kubernetes as it is?
If your application is not cloud-native and can't be containerized in its current form, we rebuild it. We rewrite the parts that block the migration, keep the business logic intact, and deliver a system that runs on modern infrastructure from day one.
Different profile?
A one-hour assessment defines the case, the constraints, and the right path forward.
Request assessmentThree ways to ship a release.
One that stops needing a window.
The release window
- The release has a time slot and a designated operator
- Rollback means redeploying the previous build by hand
- Schema changes go out in the same window as the code
- Recovery time depends on who is awake and how fast they read
- Release frequency falls as the system grows
- Customers receive maintenance announcements
Rolling update, default config
- Pods are replaced progressively, with no real gate on the replacement
- Readiness endpoints answer 200 before the application can serve
- maxUnavailable left at its default, so capacity dips during every rollout
- A failed rollout stalls halfway, with two versions live
- Reverting still waits for a human to run the command
- Schema migration stays the untested part of the release
Progressive delivery, gated
- Readiness probes written to gate traffic, not to return 200
- maxUnavailable at zero: the running version serves until the new one proves itself
- Automated revert through Argo Rollouts or Flagger, not a manual command
- Schema migrations staged so both versions read and write safely
- The pipeline promotes on the same health signal the rollout reacts to
- Standard upstream Kubernetes, no proprietary fork
Technical capabilities.
Rollout with zero unavailability
maxUnavailable set to zero. The running version serves every request until the new pods have passed their checks.
Readiness probes as a release gate
Traffic reaches a new pod only once it reports that its dependencies answer. An endpoint that returns 200 unconditionally gates nothing.
Automated revert
Rollout budgets and automatic rollback through Argo Rollouts or Flagger. Upstream Kubernetes halts a failed rollout on its own; it does not undo it.
Migrations both versions survive
Schema changes staged in expand and contract phases, so the old and the new release read and write the same database during the rollout.
Deploy on signal
The pipeline promotes a version when the health signals allow it, not when someone clicks. The same signals the rollout reacts to.
Team ownership transferred
Manifests, rollout policies, and runbooks delivered with the pipeline. Your team ships without us after handover.
Questions,
answered directly.
Is this assessment Kubernetes-specific?
No. The pattern of Rolling Update deployment with automated rollback can be implemented on multiple orchestration substrates. The assessment evaluates your current stack and identifies the right path forward, which sometimes does not involve Kubernetes at all.
What if we are already on a US hyperscaler?
The methodology is infrastructure-agnostic. If the existing setup is the right fit, the assessment confirms it and identifies the architectural changes needed within that environment. If migration is the right move, the report describes it.
What does a Cluster Setup cost?
Fixed fee based on complexity. Three tiers: Small, Medium, Complex. The exact figure is defined after the assessment, based on actual case requirements.
How long does the implementation typically take?
It depends on which of the three prerequisites is missing. Infrastructure work alone typically completes within a few weeks. Schema migration work takes longer, because it has to be staged carefully to maintain backward compatibility during the transition.
What happens after the setup?
The cluster, documentation, and operational knowledge belong to the client team. Maintenance is purchased on demand. No monthly retainer, no contractual lock-in.
Does the engineering team need prior DevOps experience?
No. Where the team needs to operate the cluster independently after delivery, GitOps training is available as an optional service. It typically takes one to two days.
Is Graftholders limited to Kubernetes work?
No. Software development and industrial cybersecurity (IEC 62443, CRA, NIS2, GDPR) are part of the offering. Clients engage through the most relevant entry point.
Diagnosis before design.
One hour with one of our engineers. A written report covering your current architecture, the constraint that makes deployment an event today, the work required to make it automatic, and a realistic timeline. The report is yours, regardless of what you decide to do with it.
Request assessment/ Response within 24 hours, with next steps