What happens after Kubernetes? A simpler production model

Once a team decides the cluster has become a burden, a very practical question follows, and it is usually the thing that stalls the whole conversation. What does production even look like without Kubernetes? You have spent years building an intuition for how your application runs, and that intuition is shaped entirely by the cluster. Deploys are manifests and rollouts. Scaling is autoscalers and node pools. Reliability is probes and replica counts. Take all of that away and the picture goes blank, which makes leaving feel less like a decision and more like a leap. So teams stay, not because they want the cluster, but because they cannot clearly see what replaces it.

If you are running a production Laravel application on EKS or GKE, and you have already concluded that Kubernetes is costing your team more than it returns, this is written for you. If your workloads genuinely need cluster-level control, or you are early in your Kubernetes journey and still learning what it offers, this is not. I am talking to the teams that have made the diagnosis and are now stuck on the alternative. This piece is about that alternative, specifically how production operations change shape when the cluster disappears. The short version is that they do not get weaker. They get smaller. Production without Kubernetes is not production with less capability. It is production with the operational layer removed, and Sevalla is built around exactly that idea: the orchestration belongs to a platform, not to your payroll.

You think you are giving up capability. You are not.#

Here is the fear that blocks almost every team at this point, and it is worth clearing before anything else, because the rest of the picture does not land until it is gone. The worry is that Kubernetes gives you real capabilities, orchestration, automatic scaling, self-healing, controlled rollouts, and that walking away means giving those capabilities up. That is the belief that keeps people tuning a cluster they have already decided they do not want.

It rests on a conflation. Kubernetes bundles two different things that feel like one. The first is a set of production capabilities: your application should scale under load, recover from failures, roll out new versions without dropping requests, and stay available. The second is the work of operating the machinery that provides those capabilities: the manifests, the node pools, the autoscaler configuration, the upgrades, the debugging. You need the first. You have been paying for it by doing the second yourself.

The move off Kubernetes does not touch the first. Your application still scales, still self-heals, still rolls out cleanly, still stays up. What changes is that you stop operating the machinery that makes those things happen. You keep every capability that mattered and hand off the labor of running it. Once you separate those two ideas, the fear dissolves, and everything below is just the detail of what that separation looks like in practice.

Deploys stop being choreography#

Think about what a deploy is on your cluster today. You build an image and push it to a registry. You update a manifest, or a Helm value, or both. You apply the change and watch the rollout. You keep an eye on the readiness probe, because if the new pods do not pass their health check the rollout stalls and you have to work out why. When it goes wrong, and it goes wrong often enough to be memorable, you are reading pod logs and describing deployments and comparing revisions. A deploy is a piece of choreography, and someone has to know the steps.

After Kubernetes, a deploy is a Git push. The build runs, the new version goes live, and the platform handles the orchestration underneath without asking you to direct it. There is no manifest to edit, no rollout to babysit, no probe to reason about. The thing that used to be a small operation with a dozen ways to fail becomes a single action with an obvious outcome. Deploying stops being an event your team plans around and becomes something a developer does without thinking about it, which is exactly what it should have been all along.

Scaling stops being a job#

On a cluster, scaling is ongoing work. You configure horizontal pod autoscalers and pick the metrics they watch. You size and manage node pools so there is somewhere for scaled pods to land. You tune thresholds, and when traffic patterns change you tune them again. Under a real spike you find out whether your guesses were right, and if they were not, someone is adjusting configuration while the incident is live. Scaling is not a setting you configure once. It is a responsibility you carry.

After Kubernetes, scaling is something the platform does and you stop thinking about. The application expands to meet load and contracts when the load passes, without a human choosing thresholds or provisioning capacity ahead of a spike. This is the difference between owning scaling and having it. Your application still scales, reliably, under real traffic. Your team is simply no longer the mechanism that makes it scale. The weekly tuning, the capacity guessing, the fear of the next spike, all of it leaves the job.

Incidents collapse to your application#

This is the change teams feel most, because it reaches into their nights and weekends. On a self-managed cluster, an incident can originate anywhere in a deep stack. Is it the application? The pod? The node? The autoscaler? The ingress? Networking? Each layer has its own diagnostics and its own vocabulary, and tracing a problem from symptom to cause means moving across all of them. That is why cluster on-call tends to land on one or two people. They are the only ones who hold the whole stack in their heads.

Remove the cluster and the failure surface collapses to your application code. When something breaks, the question is no longer which of six layers is at fault. It is what changed in the application, because that is the only layer your team still owns. That has two consequences that matter. Incidents resolve faster, because the search space is smaller and the context is familiar. And on-call stops being the private burden of the one engineer who understood the cluster, because any application developer can now respond to an application problem. The 2am page, when it comes at all, points at code your whole team can read.

The team changes shape#

Add these changes together and the shape of the team itself changes. The platform rituals go first: no pager for the cluster, no standing infrastructure backlog competing with feature work, no internal tooling built just to keep the platform legible. The single point of failure goes with them, because there is no longer a body of cluster knowledge that lives in one person and walks out the door when they leave.

What fills the space they leave is the work you actually hired for. Your senior engineers come back to the codebase and the architecture, because there is no cluster pulling them away. New developers become productive on their first day, because the thing they need to learn is your product, not your namespace conventions and your Helm layout. Your release cadence stops being gated by infrastructure work, so features that used to wait on a platform change just ship. None of this is a soft benefit. It is engineering capacity returned to the roadmap, which is the only reason to make this move in the first place.

What you actually give up#

I want to be honest about the trade, because a piece like this is worthless if it pretends there is no cost. There is one, and for a small number of teams it is decisive.

What you give up is fine-grained control of the orchestration layer. If your workloads are genuinely unusual, if you need to place specific pods on specific hardware, run exotic sidecars, or express scheduling logic that only Kubernetes can, then a platform that abstracts the cluster will take options away from you that you actually use. If you operate under data residency or compliance requirements that demand cluster-level control you can audit and prove, that is a real constraint and you should respect it. Teams in those situations should keep their cluster, and they know who they are.

For everyone else, and that is most teams running a standard Laravel application, the control you are giving up is control you were never really using. It was theoretical, held in reserve against requirements you do not have. Paying to operate a full orchestration platform for the option value of control you never exercise is not prudence. It is overhead wearing the costume of prudence. Giving up an option you were never going to use is not a sacrifice worth grieving.

The after-state, concretely#

Here is what production looks like after the cluster, a Laravel 13 application on PHP 8.5 deployed on Sevalla. This is the whole of what your team operates:

app:
  name: my-laravel-app
  runtime: php
  version: "8.5"
 
build:
  buildpacks: true
  run:
    - composer install --no-dev --optimize-autoloader
    - php artisan config:cache
    - php artisan route:cache
    - php artisan view:cache
 
workers:
  - name: queue
    command: php artisan queue:work --sleep=3 --tries=3
 
crons:
  - name: scheduler
    schedule: "* * * * *"
    command: php artisan schedule:run
 
environment:
  - APP_ENV=production
  - LOG_CHANNEL=stderr

Queues are workers. The scheduler is a cron. Environment variables live in the dashboard. There are no manifests, no Helm charts, no node pools, no autoscalers, no ingress, no probes. Your team deploys from Git. Sevalla handles runtime orchestration, networking, scaling, failover, observability, and deployment workflows behind the platform boundary. Every capability the cluster gave you is still here. The operating of it is not.

It is worth being precise about where that boundary sits, because removing cluster management is not the same as removing responsibility. Sevalla takes over the operational layer: the orchestration, the scaling, the networking, the failover, and the deployment machinery. It does not take over your application. Your code is still yours. Your configuration, your environment variables, your data and its migrations and backups, your third-party integrations, and how your service actually behaves under real users all remain your team's to own. What leaves is the work of operating infrastructure. What stays is the work of building and running a good application, which is the work you wanted your team doing in the first place. That is the trade stated plainly. You give up managing the cluster. You do not give up owning your product.

You already made the hard decision#

If you have read this far, you are not trying to work out whether Kubernetes is a burden. You settled that before you got here. The only thing that was holding you in place was not being able to see what production looked like on the other side, and now you can. It looks like every capability you relied on, with the operational layer that consumed your team removed from underneath it.

So the remaining decision is smaller than it felt, and it is not really a technical one. Your application will scale, recover, and deploy cleanly either way. The question is only who operates the machinery that makes that happen, your engineers or a platform. You have already admitted you do not want it to be your engineers.

You do not have to migrate anything to find out whether this holds. Pick one representative service, something real enough to matter but contained enough to move in an afternoon, a background worker, an internal API, or a supporting service that sits off your main cluster. Deploy it to Sevalla from Git. Point real traffic at it, watch it scale, push a change and watch it roll out, and pull the logs and metrics when you want them. One representative service tells you almost everything, because the operating model is identical whether you are running a single service or your entire platform. If that service behaves the way this article describes, you have validated the simpler production model against your own workload rather than a demo, and you move the rest knowing exactly what you are moving to.

Sevalla is where production goes when you are done operating it yourself. You made the hard call already. Deploy one service and let it make the rest of the case for you.