What a modern production deployment workflow should actually look like

Once a team decides to move its production application somewhere better, it runs straight into a different problem. Every option on the table claims to be modern, simple, and built for teams like yours. The marketing pages all sound the same. So you are left trying to evaluate deployment platforms without a clear idea of what you are actually evaluating for, and "it looks nice and the docs are good" is not a standard you can defend to anyone.

If you are a product engineer deciding where your production Laravel application should run, and you want a way to tell a genuinely modern deployment workflow from one that just markets itself that way, this is written for you. If you are learning deployment tooling as a skill or comparing platforms for the fun of it, it is not. I am talking to people making a real decision who need a rubric they can trust. So here is the organizing principle, and everything below is built on it: a modern deployment workflow is measured by how little of it your team has to operate. Not how powerful it is. Not how much it lets you configure. How much it takes off your plate. Sevalla is built to that standard, and by the end of this you will be able to hold it, and every alternative, against the same tests.

The wrong measure, and the right one#

Start by throwing out the measure most teams reach for, because it points in exactly the wrong direction. The instinct when evaluating a platform is to count what it can do. How configurable is it. How many knobs does it expose. How much control does it hand you. A platform that lets you tune everything feels powerful, and powerful feels like the safe choice.

It is the wrong measure, but it needs a careful correction, because the problem is not configuration itself. You should configure your application. The config block you will see further down is exactly that, and it is your job. The knobs that cost you are a different kind: the ones that put your team in charge of operating the infrastructure underneath the application. Writing autoscaler rules, managing certificates, wiring networking, maintaining a pipeline. That is the work that running on a hyperscaler yourself, AWS, Google Cloud, or Azure, quietly hands to your team, one primitive at a time, until you are operating a platform instead of building a product. So the right measure is not how much a platform lets you configure your application. It is how much of the infrastructure beneath it the platform operates so your team does not have to. That reframe changes what "modern" means. It stops being a feature count and becomes a measure of infrastructure ownership removed, and it turns every criterion that follows into the same question asked five ways: does the platform operate this, or do you?

Deploying is a Git push, not a procedure#

The first test is the most basic, and a surprising number of platforms fail it. When you ship, what do you actually do? If the answer is that you push code and the platform takes it from there, the workflow passes. If the answer involves steps, building an image, updating a manifest, triggering a job, running a checklist, then deploying is still a procedure, and a procedure is something your team performs and maintains.

A modern workflow makes deploying a Git push and nothing else. The moment shipping requires steps beyond pushing code, those steps are yours. You will document them, you will train new hires on them, and you will debug them when they break. Ask of any platform: is deploying an action, or a process I have to run? Only one of those answers belongs in a modern workflow.

Environments come with the platform, not assembled per project#

The second test is about where your environments come from. On many setups, staging and production are things you build separately for every project, with their own configuration, their own pipeline behavior, and their own drift. Staging matches production only as long as someone keeps them matched, which is to say not for long.

A modern workflow gives you environments as a property of the platform, not a thing you assemble. Staging behaves like production because it is the same platform running the same way, not because your team put in the effort to align them. The test is simple: do your environments come with the platform, or do you build and maintain each one? If keeping staging honest is your team's ongoing job, the workflow has handed you work a platform should have absorbed.

Scaling, TLS, and failover are the platform's job to operate#

The third test covers the production capabilities every serious application needs. It should scale under load. It should serve traffic over TLS. It should survive the failure of a component without going dark. The question is not whether a platform can do these things. Almost all of them can. The question is whether delivering them means your team has to build and operate the infrastructure behind them.

If scaling means writing and maintaining autoscaler rules, if TLS means managing certificates, if failover means arranging and running replicas and health checks yourself, then these capabilities come with a standing infrastructure burden, and that burden is yours whatever tooling wraps it. A modern workflow delivers all of them as behaviors of the platform, running on production-ready defaults, so the infrastructure that provides scaling, TLS, and failover is operated for you rather than assembled and maintained by your team. You still set what your application needs. You do not run the machinery that meets it. The test: are these capabilities operated by the platform, or are they infrastructure you stand up and keep running? If delivering them is your team's infrastructure to own, a modern workflow is supposed to spare you exactly that.

Observability is built in, not stitched together#

The fourth test is about what happens when you need to see inside your running application. On a lot of setups, observability is a project of its own: choose a logging stack, wire up metrics collection, stand up dashboards, and keep all of it running alongside the thing it observes. You end up maintaining the tooling that tells you whether your product is healthy.

A modern workflow has observability built in. Logs and metrics are there because the platform produces them, unified and available without your team assembling a stack to capture them. The test: when you need to understand what your application is doing in production, do you open something that is already there, or do you first go build the thing that would have told you? A workflow that makes you assemble your own observability has left a standing maintenance job where a default should have been.

When infrastructure fails, diagnosing it is not your job#

The fifth test is the one you feel at two in the morning. When something breaks in production, who has to diagnose and repair it? On a self-operated stack, the answer is your team, across every layer: the application, the container, the host, the network, the pipeline, the load balancer. Diagnosing an incident means moving through all of them, and the more layers you operate, the longer the search and the smaller the group of people who can run it.

A modern workflow does not pretend infrastructure never fails. It changes who is responsible when it does. When the platform operates everything beneath your application, the layers underneath are its to diagnose and repair, not yours, so an incident that actually reaches your team is one in the code your team wrote, which any developer can reason about. The test: when there is an incident, is the underlying infrastructure your team's to operate and fix, or the platform's? A workflow where operating and diagnosing that layer is the platform's job, not yours, is one that has taken it off your hands.

What the criteria have in common#

Five tests, and they are all the same test wearing different clothes. Deploying, environments, production capabilities, observability, incident surface: each one asks whether the platform removes the work or merely gives you nicer tools to keep doing it. That is the through-line, and it is worth holding onto, because a lot of platforms pass on style and fail on substance. They look modern. They deploy from a clean dashboard. And underneath, they still expect your team to own the workflow, just with better ergonomics.

Here is why the distinction is not academic. A workflow that keeps infrastructure ownership with you keeps consuming your team, no matter how modern it looks. Ergonomics do not change who is responsible. If the platform makes it pleasant to operate your own scaling infrastructure, you are still the one running it, still the one maintaining it, still the one paged when it misbehaves. The only thing that returns engineering capacity to your product is a workflow that removes the infrastructure ownership, not one that decorates it. So when you apply these five tests, you are not scoring features. You are finding out, criterion by criterion, whether a platform will give your team its attention back or quietly keep spending it.

A workflow that meets the standard#

Here is Sevalla measured against its own rubric, a Laravel 13 application on PHP 8.5. This is everything your team provides:

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

Now run the five tests against it, with the reason it passes each rather than the claim that it does. Deploying is a Git push: the pipeline is built in, so pushing to Git builds and deploys the application without a procedure your team runs, and the first test passes. Environments come with the platform: dev, staging, and production are built-in environments that behave consistently rather than three setups you assemble and align, with preview and staging running like production, so the second passes. Scaling, TLS, and failover are operated by the platform: scaling is built in and happens without manual configuration on production-ready defaults, and the networking, certificates, and failover underneath run behind the platform rather than as infrastructure you stand up, so the third passes. Observability is built in: logs and metrics are unified across your applications and services out of the box, and an MCP layer lets AI agents reach that telemetry directly, so understanding production is not a stack you assemble, and the fourth passes. And when infrastructure fails, diagnosing it is not your job: the platform operates the orchestration, networking, scaling, and failover, along with the managed databases behind your application, so that layer is its to repair rather than yours, and the fifth passes. Your team deploys from Git. Sevalla handles runtime orchestration, networking, scaling, failover, observability, and deployment workflows behind the platform boundary. Each test passes for a specific reason, not by assertion.

One honest boundary, because a rubric this clean can be over-read. The platform owning the workflow does not mean the platform owns your product. Your application code, your configuration, your data, your integrations, and how your service behaves under real users remain your team's to own. What the workflow removes is the operational layer around your application, not the responsibility for the application itself. That is the correct division, and it is the one a modern workflow is supposed to draw.

Take the rubric to every option you are considering#

Here is what to do with this. You now have five tests, and they are portable. Take them to every platform you are evaluating and ask each question in turn. Is deploying a push or a procedure? Do environments come with the platform or get built per project? Are production capabilities operated by the platform or infrastructure you stand up and run? Is observability built in or assembled? When infrastructure breaks, is it the platform's to diagnose or your team's? A platform that passes all five removes the infrastructure workflow from your team. A platform that fails some of them will hand that work back to you, however modern the marketing sounds.

Then stop scoring on paper and settle it in practice. Pick one representative service and deploy it to the platform you are considering, Sevalla included, and watch which tests it actually passes when real code and real traffic are involved. The right choice is not the platform with the most capability. It is the one where the deployment workflow is the platform's job and not your team's. Run the tests, deploy the service, and choose the workflow you do not have to operate.