Interview with Sevalla

Is the name “Sevalla” just a play on the location in Sweden? Does it have deeper meaning?

Yes, it’s a nod to Sweden, just like Kinsta.

Kinsta turned out to share its name with a small Swedish village (something we discovered after launch), and that brand went on to power thousands of serious production workloads. When we spun out our application and database platform into its own identity, the team wanted something distinct, but connected.

Sevalla is also the name of a Swedish village. There’s no hidden acronym or technical meaning behind it. We simply liked the continuity. One small Swedish name worked out pretty well. We decided to trust the pattern.

The difference now is this: Sevalla isn’t an experiment. It’s a developer-first PaaS built for teams running production applications who want power without hyperscaler overhead.

Sevalla is officially labeled “a Kinsta product,” but it has its own brand, its own dashboard, and its own API. How do you think about the relationship between these two products — are they siblings, parent-child, or something else entirely?

Sevalla operates as its own platform and brand, with its own roadmap, dashboard, API, and product direction.

At the same time, it’s infrastructure-backed by Kinsta. That means Sevalla benefits from over a decade of operational experience running high-performance, production hosting at scale.

The relationship isn’t parent-child. It’s more like a focused spin-out with shared foundations.

Kinsta remains the WordPress specialist. Sevalla exists for teams running custom applications, databases, and services that want production power without running Kubernetes or stitching together hyperscaler infrastructure.

We deliberately separated the brands to remove confusion and allow each to evolve independently. Sevalla can optimize for developer-first PaaS simplicity. Kinsta can stay laser-focused on WordPress excellence.

Independent execution with a shared operational DNA.

You originally launched PaaS services under the Kinsta brand and later spun them out into Sevalla. What wasn’t working about keeping everything under one roof, and what was the moment you realized it needed its own identity? Was it a hard move?

Launching under the Kinsta brand made sense at the time. We had strong traffic, brand equity, and an existing customer base. It gave the PaaS offering distribution on day one.

But over time, it became clear we were serving two very different audiences under one roof.

Kinsta’s core customers are WordPress teams. They care about publishing, performance, and reliability. Most of them do not need application hosting or database infrastructure. Putting those options in the same dashboard added complexity for people who did not ask for it.

At the same time, developers running custom applications do not want to land on a WordPress-focused site. They are looking for CI/CD workflows, container builds, preview environments, multi-region support, and production control without managing Kubernetes or navigating hyperscaler infrastructure themselves.

Trying to speak to both groups on one platform diluted the message and the product experience.

The turning point was recognizing that clarity would unlock growth. Sevalla needed its own identity so we could speak directly to production application teams without confusing Kinsta’s WordPress base.

Was it a hard move? Operationally, yes. Strategically, no.

Once the audience mismatch was obvious, separating the brands was the only logical path. It allowed Kinsta to stay focused on WordPress excellence and gave Sevalla the freedom to become a serious, developer-first PaaS.

Separating the brands gave both products the clarity and focus required to scale properly.

A lot of our audience run WordPress agencies. Give them the pitch — why should they care about Sevalla? What’s the use case that should make them pay attention?

Most serious WordPress agencies are no longer just WordPress shops.

They build client portals, SaaS products, internal tools, APIs, and custom applications alongside their WordPress projects. The moment they step outside WordPress, they usually end up managing their own AWS, Azure, GCP, or some mix of infrastructure.

That means dealing with Kubernetes clusters, networking, IAM policies, unpredictable billing, and DevOps overhead that pulls engineers away from client work.

Sevalla exists for that gap.

It provides agencies with a production-ready platform for Laravel, PHP, Python, Node.js, and other frameworks without forcing them to become cloud operators. CI/CD, preview environments, and production-ready databases are built in. The operational heavy lifting is handled for them.

If Kinsta removed complexity for their WordPress workloads, Sevalla does the same for everything else they build.

For agencies, the use case is simple: expand beyond WordPress without inheriting hyperscaler complexity or margin erosion.

That is why they should care.

I saw the Jala Design case study — a WordPress agency that built an internal staff portal on Sevalla using Express and Next.js. Is that the typical pattern you’re seeing? Agencies using Sevalla for the non-WordPress stuff they need to build?

Yes, that pattern is common.

WordPress agencies increasingly build internal tools, SaaS extensions, client portals, and custom applications alongside their WordPress projects. Those projects often run on Node, Laravel, Python, or other frameworks that fall outside traditional WordPress hosting.

Before Sevalla, that usually meant spinning up AWS, Azure, or GCP infrastructure and managing the operational complexity themselves.

In Jala’s case, they built an internal staff portal using Express and Next.js. Their feedback was straightforward: running a Node stack previously required heavy DevOps overhead. With Sevalla, they deploy TypeScript, Next.js, and Express applications without managing servers.

That is the pattern we see repeatedly.

Agencies keep WordPress workloads on Kinsta, where the tooling is purpose-built for WordPress. They use Sevalla for everything else, giving them production-grade application hosting without dealing with Kubernetes or hyperscaler configuration.

It allows them to expand their service offering without expanding their DevOps burden.

That is the consistent use case we are seeing.

You have an agency program with custom pricing. What does that actually look like in practice, and what size agency starts to benefit from it?

The agency program is built for teams running multiple production workloads across clients.

In practice, agencies start to benefit once they are managing multiple live applications or environments. That often means a team of 5 to 10 developers with multiple active client builds, internal tools, or SaaS extensions.

At that point, two things matter: Margin and predictability

Instead of paying per seat or navigating unpredictable hyperscaler billing, agencies can structure hosting around their real usage profile. Whether that is a few heavier production apps or a larger number of smaller environments, the goal is cost clarity and margin protection.

We look at current workloads, growth plans, and deployment patterns. Then we align pricing with how the agency actually operates.

It is less about a strict headcount threshold and more about operational scale. Once infrastructure management starts eating into billable time or cloud costs become difficult to forecast, the agency program becomes valuable.

The objective is simple: protect agency margins while they scale.

WordPress hosting support is very specific — “my plugin broke,” “my site is slow.” What does support look like on the Sevalla side when someone can deploy literally anything in a Docker container? How do you scope what you’ll help with?

Support on Sevalla is platform-focused and clearly defined.

Because teams can deploy almost anything in a container, the surface area is broader than WordPress hosting. Our support team helps with issues related to the hosting platform itself.

That includes:

• Troubleshooting while adding applications, static sites, or databases
• Problems with default deployment features such as Nixpacks, Buildpacks, environment variables, processes, and connections
• Domain verification issues
• Platform and infrastructure availability
• Connectivity between Sevalla-hosted applications and databases

If the issue lives in the infrastructure layer or within Sevalla’s default deployment system, we step in.

What we do not do is assume responsibility for development. We do not debug application logic, fix framework-specific errors, audit code, troubleshoot missing dependencies, or assist with Git conflicts. We also do not perform migrations to or from Sevalla.

The boundary is intentional.

Sevalla provides a production-ready platform for hosting applications, databases, and static sites. You own your code and application behavior. We own the platform’s reliability and functionality.

That clarity matters when you are running production workloads.

Is there a future where Sevalla and Kinsta converge again — say, headless WordPress on Kinsta with a Next.js frontend on Sevalla as a single managed experience? Or are they intentionally going in different directions?

They are intentionally moving in different directions.

Kinsta is focused on being the best-managed WordPress platform. Sevalla is focused on being a developer-first PaaS for custom applications, databases, and services.

Bringing them back together into a single managed experience would reintroduce the same audience confusion we worked hard to remove. WordPress teams and application teams have different expectations, workflows, and support needs. Keeping the platforms separate allows each to stay opinionated and optimized for its core user.

That does not mean they cannot complement each other.

If an agency wants to run WordPress on Kinsta and a Next.js frontend or API service on Sevalla, that architecture makes sense. The platforms can coexist cleanly without being merged into one dashboard.

Separation creates clarity. Clarity allows both products to evolve faster.

That is the direction we are committed to.

If you were starting a brand new web project today — not WordPress, just a modern web app — what would your stack look like on Sevalla, and how fast could you actually go from zero to production?

If I were starting a modern web app today, I would keep it simple.

Frontend: Next.js

Backend: Node with Express or a lightweight API layer

Database: Managed PostgreSQL

Everything is containerized and deployed through Git.

On Sevalla, I would connect the repository, let Nixpacks or Buildpacks handle the build, provision a PostgreSQL database, set environment variables, and push to main.

Preview environments would spin up automatically for pull requests. Pipelines would handle staging and production promotion.

From zero to a live production environment, you are realistically looking at minutes to first deploy. A few hours to production-ready.

The difference is speed without the need for infrastructure setup. You focus on the app. The platform handles the rest.

That is the experience we are optimizing for.

I know you’re biased, but I think hosts will play a vital role in an “open AI” ecosystem where there will be more opinionated models to deploy. Brands and organizations might want to host their own model off prem, and today’s “web host” might be the solution. What’s your outlook on how hosting evolves with customer AI demands?

Hosting is going to become more opinionated, not less. The era of raw infrastructure is fading.

AI tools are already changing how code is written and deployed. Tools like Claude Code and other agent-assisted workflows are accelerating development. That means teams are shipping more services, APIs, and experimenting more.

The bottleneck shifts from writing code to running it reliably.

Not every company will train its own foundation model. But many will run inference services, internal agents, retrieval pipelines, and AI-enabled applications that need predictable infrastructure.

That is where hosting evolves.

The future is not just static sites and databases. Containerized workloads may include model inference services, vector databases, background workers, and event-driven pipelines. Teams will want to run those without stitching together hyperscaler primitives.

Our outlook is practical. Sevalla should be the place where modern workloads run cleanly in production, whether they are traditional web apps or AI-enabled services.

AI increases the number of services teams deploy. It does not eliminate the need for reliable infrastructure. If anything, it increases it.

That is the role hosting will continue to play.

Any parting advice for the WordPress community or agency owner that might be “stuck” thinking about the old ways of hosting or delivering client solutions? 

If you are still solving every client problem with a VPS and manual server setup, you are spending energy in the wrong place.

The market has moved.

Clients expect faster iteration, cleaner deployments, and the ability to expand beyond WordPress when needed. That means running modern stacks, shipping APIs, building internal tools, and launching SaaS extensions without turning every project into a DevOps exercise.

You do not have to become a cloud infrastructure expert to do that.

The smart move is to understand modern platforms before you need them. Spin up an app. Connect a repo. See what a production pipeline looks like without manually configuring servers.

When a client asks for something beyond WordPress, you should be able to say yes without hesitation.

The agencies that win over the next decade will not be the ones managing servers. They will be the ones shipping.

That is the shift.