The case for managed hosting

Most conversations about managed hosting start in the wrong place. They start with pain: the AWS bill, the deployment pipeline that breaks on Friday afternoons, the senior engineer who holds all the infrastructure knowledge and is thinking about leaving. Those are real problems and they are worth taking seriously.

But the case for managed hosting does not rest on pain. It rests on a more direct argument: managed hosting is not a tradeoff between control and convenience. It is the correct infrastructure decision for the overwhelming majority of product engineering teams, made for strategic reasons that stand on their own regardless of how much operational pain the current setup is generating.

This article makes that case directly.

The abstraction argument#

Every engineering decision is a decision about which abstractions to own and which to delegate. A product engineering team writes application code and delegates the operating system. It uses a framework and delegates the HTTP layer. It uses a managed database and delegates the storage engine. Nobody argues that writing your own HTTP server or storage engine is the serious, professional approach to building a product. Those are layers where the abstraction has been proven, the delegation is clearly correct, and owning the layer would be a distraction from the actual work.

Infrastructure is the same kind of layer. The question is not whether to delegate it but when. Most teams running self-managed infrastructure reached the point where delegation was the correct call and kept going anyway, either because the tooling was not good enough at the time or because the habit of ownership was already established and nobody stopped to question it.

The abstraction is now good enough. Managed platforms in 2025 handle runtime orchestration, networking, scaling, failover, observability, and deployment workflows at a level of reliability that equals or exceeds what most product teams can build and maintain themselves. The case for owning the infrastructure layer, which was always marginal for most product teams, has become harder to make with every year that managed platforms have matured.

Delegating infrastructure is not a shortcut. It is the correct application of an engineering principle that the same teams apply everywhere else in their stack.

What hyperscaler ownership actually requires#

The argument for delegating infrastructure becomes concrete when you look at what owning it actually demands.

On AWS, a production application requires an Application Load Balancer, EC2 or ECS for compute, RDS for the database, ElastiCache for Redis, SQS for queues, S3 for file storage, CloudWatch for logs and alerting, Route 53 for DNS, ACM for TLS certificates, and IAM to wire permissions between all of it. IAM alone is a discipline. Every service-to-service permission relationship has to be explicitly defined: the ECS task role that allows the application to read from S3, the deployment pipeline role that allows GitHub Actions to push to ECR and update ECS task definitions, the Lambda execution role that allows the function to write to CloudWatch. Get one of those wrong and something fails silently, or fails loudly in production at the wrong moment.

ECS task definitions version with every deployment. Getting a deployment to stabilise requires the new container to pass its health check within a configured window. If the application takes longer to boot than the health check allows, ECS rolls back, the deployment fails, and someone has to know where to find the task failure logs and what they mean. On EKS or a self-managed Kubernetes cluster, the same deployment also involves Deployment manifests, readiness and liveness probes, resource requests and limits, Ingress controller configuration, and a cluster upgrade cycle that runs every four months and cannot be deferred indefinitely.

Google Cloud and Azure follow the same pattern with different service names. The primitives change. The operational burden does not.

Environment drift compounds all of it. Staging and production start identical and diverge through the accumulated effect of operational decisions made under pressure: a configuration change applied in production during an incident that never gets backported, an environment variable added directly to the console because the deploy was urgent and Terraform could wait, a security group rule loosened temporarily that is still temporary a year later. The staging environment that was supposed to be a reliable proxy for production is no longer quite that, and the gap surfaces as surprises at deployment time.

On Sevalla, none of that surface area belongs to your team. Your team deploys from Git. Sevalla handles runtime orchestration, networking, scaling, failover, observability, and deployment workflows behind the platform boundary. The IAM policies, the ECS task definitions, the health check configuration, the Ingress rules: none of those are decisions your engineers make or failures your engineers diagnose. The operational surface is the application code, and the application code is already what your engineers know.

"With Sevalla, you no longer need to worry about uptime or managing infrastructure — it simply works. If I were to start a new project today, I would choose Sevalla from the very beginning." — Jorik Kraaikamp Mulder, Lead Backend Developer, Stepler

The focus argument#

Product engineering teams have a finite amount of engineering attention. That attention is the most valuable resource the team has, and it is the resource that self-managed infrastructure consumes most wastefully.

The work that builds a product, that creates competitive advantage, that drives growth, lives in the application layer. The features, the user experience, the business logic, the integrations, the performance improvements that users notice. Every hour of engineering attention that goes to the infrastructure layer is an hour not going to the product layer, and the substitution is not symmetrical. Infrastructure work produces operational stability. Product work produces growth. A team that is equally divided between the two is running at half the product velocity of a team that can direct its full attention to the product.

The roadmap impact is direct and measurable. The sprint where a senior engineer spent two days debugging a failed ECS deployment is a sprint where the architectural improvement that was supposed to ship did not. The quarter where engineers were absorbed by a Kubernetes cluster upgrade is a quarter where a competitor shipped features the team did not. The features sitting in the backlog marked "blocked: infrastructure dependency" are not blocked by complexity in the code. They are blocked by the operational overhead of the platform the code runs on.

Managed hosting is how a product team buys back that attention permanently. Not by hiring a DevOps engineer to absorb the infrastructure work, which transfers the burden without eliminating it. Not by improving processes or documentation, which reduces the overhead without addressing the source. By delegating the layer entirely to a platform whose job is to handle it, so the product team can do the job it was built to do.

The infrastructure exists. It runs reliably. Your engineers never touch it. Their attention stays on the product. That is not a convenience feature. It is a structural change in how the team's most valuable resource is allocated, and it shows up in the roadmap every sprint.

The reliability argument#

The instinct that keeps teams on self-managed infrastructure is often framed as a reliability concern. If we own it, we control it. If we control it, we can make it reliable. If we delegate it, we are dependent on someone else's reliability.

That instinct inverts the actual reliability picture for most product teams.

Running infrastructure reliably requires sustained investment in people, process, and tooling: engineers with deep platform expertise, runbooks kept current, monitoring tuned correctly, incident response processes that work at 2am. Most product engineering teams do not have all of these at the level required to deliver reliability that matches what a managed platform delivers as its core product.

Sevalla's reliability is not a function of effort or expertise your team has to provide. It is the output of a platform that exists entirely to make that layer reliable, that has done it at scale across many applications, and that is accountable for it in a way that an internal team operating infrastructure as a side responsibility is not.

For most product teams, moving to managed hosting improves reliability rather than reducing it. The failure modes that affect a self-managed stack — misconfigured IAM policies, environment drift between staging and production, ECS health checks that time out after a deploy because the new container boots slightly slower, deployment pipelines that fail in AWS-specific ways that require AWS-specific knowledge to diagnose, operational knowledge that lives in one person's head and leaves with them when they resign — those failure modes are eliminated rather than managed. The failure surface narrows to the application layer, where the team already has the expertise to respond.

The talent argument#

Self-managed infrastructure has a talent cost that most teams underestimate at the point they make the infrastructure decision and feel acutely later.

Running a complex self-managed stack well requires engineers with specific platform expertise. Those engineers are expensive, their skills command a premium in the market, and the value they provide to a product company is almost entirely operational rather than product-building. Hiring them is a commitment to maintaining the infrastructure complexity that makes them necessary. Losing them is a risk event, a concentration of operational knowledge in one person's departure that cannot be fully mitigated through documentation or cross-training.

The teams that move to managed hosting change their talent requirements. They no longer need infrastructure specialists to keep the lights on. They need product engineers who are excellent at building software. That pool is larger, less specialised, and the value engineers from it provide is directly in the product rather than in the operational layer beneath it.

Managed hosting also changes what it means to be productive as a new engineer on the team. On a self-managed stack, a new engineer spends weeks acquiring the infrastructure context required to deploy safely and respond to basic incidents. On Sevalla, they deploy on their first week. The gap between joining the team and contributing to the product is measured in days, not weeks.

The decision that serious teams make#

There is a persistent cultural assumption in the software industry that serious, sophisticated engineering teams run their own infrastructure. That AWS, or Kubernetes, or a custom stack is the mark of a team that knows what it is doing. That managed platforms are for teams that are not ready for the real thing.

This assumption is wrong, and it is worth naming directly.

The teams that choose managed hosting are not making a less sophisticated infrastructure decision. They are making a more strategically aware one. They have assessed the full cost of infrastructure ownership, including the engineering time, the knowledge concentration risk, the talent cost, and the roadmap impact, and concluded that the control they would be exercising is control over decisions that do not advance their product.

The most effective product engineering teams are the ones that are ruthlessly deliberate about where they invest their engineering attention. They own the layers that create competitive advantage. They delegate the layers that do not. Infrastructure is almost never a source of competitive advantage for a product company. The product is. The teams that understand this build better products faster, compound their advantage over time, and do not spend their careers managing IAM policies.

What the affirmative case amounts to#

Managed hosting is the correct default infrastructure choice for product engineering teams. Not because it is easier, although it is. Not because it is cheaper in full-cost terms, although it is. Because it is the decision that lets the team be what it is: a group of engineers whose job is to build a product that creates value for users and growth for the business.

The infrastructure should run quietly in the background. Your team deploys from Git. The platform handles the rest. The engineering attention that was going to the operational layer goes to the product layer instead. The roadmap moves faster. The team grows without the infrastructure complexity growing alongside it. New engineers contribute from day one. Incidents surface at the application layer where the team already has the context to resolve them.

That is not a reduced version of production engineering. It is the version where the team is doing the work it was built to do, on a platform that exists to make that possible.

Sevalla exists for the 90% of teams who should not be running AWS at all. If your team is in that 90%, the affirmative case for managed hosting is the case for getting your engineering team back. Sevalla is where that starts.