A customer reports that your application is failing in production. You try the exact same workflow on your development machine, but everything works perfectly. Your teammates can't reproduce the issue either. Automated tests pass. There are no obvious code changes that explain the failure.

Meanwhile, customers continue to experience the bug.

These issues are among the most difficult to solve because the problem often isn't the code itself. It's the environment the code is running in. Differences in configuration, infrastructure, traffic patterns, operating systems, dependencies, or production data can expose bugs that never appear during development.

Here's the uncomfortable truth: most of that difficulty is self-inflicted. Every server you manage, every log pipeline you wire together, and every configuration file you maintain by hand adds to an invisible infrastructure tax. And you pay that tax at the worst possible moment, when production is down and customers are waiting.

Fortunately, production-only bugs can be investigated systematically. In this article, you'll learn how to approach these issues using logs, metrics, distributed tracing, and environment analysis. You'll also see why applications running on a Platform as a Service (PaaS) are significantly easier to debug when things go wrong, because someone else is paying the tax for you.

What We'll Cover:

• Why Does Production Behave Differently?

• Start with Evidence, Not Assumptions

• Logs Tell You What Happened

• Metrics Reveal Trends

• Distributed Tracing Connects Every Service

• Reproduce Production as Closely as Possible

• Isolate Environmental Variables

• A Simple Production-only Bug

• Verify the Deployment Itself

• Do You Actually Need a PaaS?

• Why Debugging is Easier on a PaaS

• Build Applications That Are Easy to Debug

Why Does Production Behave Differently?

Many developers think of production as simply a larger version of their local machine.

In reality, production environments are often very different.

A production application may run across multiple servers or containers behind a load balancer. It may connect to databases containing millions of records, communicate with third-party APIs, use distributed caches, process background jobs, and serve thousands of concurrent users.

Even seemingly small differences can introduce unexpected failures.

Imagine testing an API locally using simple English names like "John Smith." Everything works perfectly. In production, a customer submits a name containing emojis or accented characters, triggering an encoding issue that was never covered by your tests.

Or perhaps your application assumes an environment variable always exists because it's configured on every developer machine. During deployment, that variable is accidentally omitted, causing production requests to fail.

The code hasn't changed. The environment has.

Notice what these failures have in common. None of them are business logic problems. They're environment problems, and every piece of infrastructure your team owns and configures by hand is another surface where your environment can silently drift away from what your code expects. The more infrastructure you manage yourself, the more of these surfaces exist.

Understanding that production behaves differently is the first step toward diagnosing these issues.

Start with Evidence, Not Assumptions

When production starts failing, it's tempting to immediately start editing code.

Resist that temptation.

The fastest way to solve complex bugs is to gather evidence before making changes.

Start by answering questions such as:

• When did the issue begin?

• Did it appear immediately after a deployment?

• Does it affect every customer or only a small group?

• Is every application instance failing?

• Did infrastructure metrics change around the same time?

Every answer narrows the search space.

But here's what nobody tells you: how quickly you can answer these questions depends almost entirely on your infrastructure, not your debugging skills.

If deployment history lives in one system, logs in another, and metrics in a third, answering even the first question means logging into three tools and manually lining up timestamps. The investigation can stall before it starts, not because the bug is hard, but because your tooling is fragmented.

Instead of guessing what might be wrong, you're building a timeline of events that points toward the root cause.

Good debugging is an investigation, not an experiment. And an investigation is only as fast as your access to the evidence.

Logs Tell You What Happened

Application logs are usually the first source of information during an incident.

Unfortunately, many applications generate logs that provide almost no useful context.

A message like this offers very little value:

Error processing request.

Compare that with this example:

Timestamp: 2026-07-13T09:41:17Z
RequestId: 91df72
CustomerId: 48291
Endpoint: POST /orders
Database: OrdersDB
Duration: 3.2 seconds
Exception: TimeoutException

Now you know when the failure occurred, which customer experienced it, which endpoint was affected, how long the request took, and what exception caused it.

So where does each of these logs come from? The first one is what you get by default. It's the product of a hurried catch block written while the developer was focused on the happy path, something like this:

catch (Exception)
{
    logger.LogError("Error processing request.");
}

The exception is caught, but everything useful about it, including the exception itself, is thrown away. The log message records that something failed, but nothing about what, where, or for whom.

The second log doesn't come from a fancier tool. It comes from a developer deciding, at the moment they wrote the code, what a future 3 a.m. investigator would need to know.

In practice, useful logs come from a few deliberate habits:

• Always log the exception object itself, not just a message, so the type and stack trace are preserved.

• Attach request context automatically. Most web frameworks let you enrich every log entry with values like a request ID or customer ID once, in middleware, instead of repeating them in every log statement. In ASP.NET Core, for example, logging scopes do exactly this.

• Record what the code was doing, like the endpoint, the downstream dependency being called, and how long it took, because those are the first questions an investigator asks.

Here's what that looks like in code:

catch (TimeoutException ex)
{
    logger.LogError(ex,
        "Order creation failed for {CustomerId} on {Endpoint} after {Duration}s",
        customerId, "POST /orders", stopwatch.Elapsed.TotalSeconds);
}

A good rule of thumb: write every log message for the person debugging an outage six months from now, who has never seen this code. That person is often you.

Notice that the message above uses named placeholders like {CustomerId} instead of string interpolation. That's structured logging: instead of flattening everything into one plain-text sentence, each value is stored as a separate named field alongside the message, typically as JSON. The entry above might be stored as:

{
  "message": "Order creation failed for 48291 on POST /orders after 3.2s",
  "CustomerId": 48291,
  "Endpoint": "POST /orders",
  "Duration": 3.2,
  "Exception": "TimeoutException"
}

The payoff is searchability. With plain-text logs, finding every failure for one customer means fuzzy text matching and luck. With structured logs, your monitoring system can run a precise query like CustomerId = 48291 AND Exception = TimeoutException and filter millions of entries in seconds. Libraries like Serilog, or the built-in ILogger in .NET, support this out of the box.

The goal isn't simply to record errors. The goal is to provide enough context that someone investigating the issue can immediately begin asking the right questions.

There's a catch, though. Great logs are worthless if you can't find them.

In self-managed setups, logs are scattered across servers, and teams end up building and babysitting their own aggregation pipelines just to make logs searchable. That's engineering time spent on plumbing, not on the product.

If your team maintains its own log shipping infrastructure, it's worth asking: why are we still doing this ourselves?

Metrics Reveal Trends

Logs explain individual events while metrics explain overall system behavior.

Suppose users report that your application becomes slow every afternoon. Reading thousands of log entries may not reveal anything unusual.

A metrics dashboard, however, might immediately show that CPU usage spikes above 90%, memory consumption steadily increases throughout the day, database latency doubles after lunch, and HTTP error rates climb sharply during peak traffic.

Let's make that concrete with the most common open-source setup: Prometheus for collecting metrics and Grafana for visualizing them.

The workflow has three parts. First, your application exposes its metrics. Most frameworks have a library for this. In ASP.NET Core, adding the prometheus-net package and one line of configuration publishes a /metrics endpoint that reports counters like request totals, response durations, and error counts.

Second, a Prometheus server scrapes that endpoint every few seconds and stores the values as time series.

Third, Grafana turns those time series into dashboards.

Once that's in place, investigating the "slow every afternoon" report stops being guesswork. You open Grafana, set the time range to the last three days, and run a query like this against Prometheus:

rate(http_request_duration_seconds_sum[5m])
/ rate(http_request_duration_seconds_count[5m])

That expression plots your average request duration over time. If the graph shows latency climbing every day between 1 p.m. and 4 p.m., you've confirmed the pattern in about a minute. Adding a second panel that plots CPU usage or database connection counts on the same time axis tells you which resource degrades first, and that's your suspect.

Those observations immediately narrow your investigation. Instead of wondering where to start, you now know exactly when the problem begins and which component is under stress.

Metrics transform isolated failures into recognisable patterns.

But that dashboard doesn't build itself. Someone has to install the agents, configure the exporters, size the time-series database, and keep the whole monitoring stack alive.

In many teams, the monitoring system itself becomes another production system that fails and needs debugging. Monitoring your monitoring is the infrastructure tax at its most absurd, and it's a strong signal that your team is carrying operational weight it never needed to.

Distributed Tracing Connects Every Service

Modern applications rarely consist of a single application talking to a single database.

A customer request may travel through an API gateway, authentication service, order service, payment processor, inventory system, cache, message queue, and database before returning a response.

When something fails, which service caused the delay?

Distributed tracing answers that question. A trace records the complete lifecycle of an individual request as it moves through your architecture. Each unit of work within the trace, like one service call or one database query, is called a span, and every span records when it started and how long it took.

Here's what a real trace looks like when viewed in a tool like Jaeger or Zipkin. A customer reports that checkout is timing out, you look up the trace for their request ID, and you see a waterfall like this:

Trace 8f3ac21 — POST /checkout — total: 4.61s

api-gateway            ████                                    45ms
  auth-service         ██                                      38ms
  order-service        ████████████████████████████████████  4.51s
    inventory-db query ██████████████████████████████████    4.29s  ⚠
    payment-api        ███                                    210ms
  response             █                                       12ms

Reading it takes seconds. The request spent 4.29 of its 4.61 seconds inside a single inventory database query. The gateway, auth service, and payment API are all healthy. Nobody needs to investigate them, and nobody needs to guess.

Under the hood, this works because the first service assigns the request a unique trace ID and passes it along in a header with every downstream call. Each service records its spans against that same ID, so the tracing backend can stitch the full journey back together.

The open standard for all of this is OpenTelemetry, which has instrumentation libraries for every major language, and in many frameworks enabling it is a few lines of setup rather than manual code changes.

Without tracing, engineers often investigate the wrong service for hours. With tracing, the slowest or failing component is usually visible within seconds.

The problem is that rolling out tracing yourself is a project, not a checkbox. Instrumenting every service, deploying collectors, and storing trace data all take real engineering effort, which is why so many teams that know they need tracing still don't have it.

When observability is something you assemble rather than something your platform provides, it tends to remain permanently on the roadmap while incidents keep arriving on schedule.

Reproduce Production as Closely as Possible

Sometimes logs and traces aren't enough. Eventually you'll need to recreate the production environment.

That doesn't necessarily mean copying your production database onto your laptop. Instead, you'll want to identify the differences between environments.

• Is production running Linux while developers use Windows or macOS?

• Does production use Redis while development does not?

• Are different runtime versions installed?

• Are requests routed through a reverse proxy?

• Does the production process handle significantly larger datasets?

• Does production receive hundreds of concurrent requests while development receives only one?

Each difference becomes a potential explanation for the bug.

How do you actually close those gaps? A few techniques cover most of them:

Containerize the Application

If production runs your app in a container, run the same image locally and in staging. This single step eliminates operating system, runtime version, and dependency differences at once, because the container carries its environment with it.

Define Infrastructure and Configuration as Code

Services like Redis, the reverse proxy, and their settings should come from checked-in configuration (a docker-compose.yml, Kubernetes manifests, or Terraform) rather than manual setup.

When staging and production are generated from the same files, they can't quietly disagree. When you need to know whether production sits behind a reverse proxy or what runtime it uses, you read it from the config instead of asking whoever set up the server.

Make the Data Realistic

You rarely need real production data, and for privacy reasons you usually shouldn't use it. What you need is data with production's shape: similar volume, and similar messiness.

Seed staging with a few million generated rows, and include the awkward cases, like names with accents and emojis, null-heavy records, and very long strings.

Simulate Production Traffic

A bug that only appears under a hundred concurrent requests will never show up when you test one request at a time. Load-testing tools like k6 or JMeter let you replay realistic concurrency against staging with a short script, which is often what finally reproduces race conditions and connection pool exhaustion.

The closer your staging environment resembles production, the more likely you are to reproduce production-only failures before customers encounter them.

Notice, again, where the effort goes. Keeping staging faithful to production is a permanent maintenance job when both environments are hand-built, because hand-built environments drift the moment someone applies a patch to one and forgets the other.

Teams that get environment parity for free, because every environment is generated from the same configuration, simply have fewer production-only bugs to chase in the first place.

Isolate Environmental Variables

One of the most effective debugging techniques is changing only one variable at a time.

Imagine your application fails only in production. Potential differences include operating system versions, database engines, container configuration, environment variables, memory limits, network latency, or infrastructure settings.

Instead of modifying several variables simultaneously, test each one individually.

Here's what that looks like in practice. Suppose an API endpoint crashes in production but works locally, and you've identified three differences: production runs PostgreSQL 16 while you develop against 15, production caps the container at 512 MB of memory, and production sets ENVIRONMENT=production.

Don't change all three at once. Test them one at a time, keeping everything else identical:

# Test 1: only the database version changes
docker run -d -p 5432:5432 postgres:16
# → run the failing request. Still works? Postgres is cleared. Revert to 15.

# Test 2: only the memory limit changes
docker run --memory=512m my-app
# → run the failing request. Crashes with an OutOfMemoryError? Found it.

If the bug appears in test 2 and only test 2, you've found your cause, and just as importantly, you've cleared the other suspects. Had you changed the database version and the memory limit together and seen the crash, you'd still have to untangle which one was responsible.

This disciplined approach often identifies the real cause much faster than random experimentation.

It's also worth pausing on that list of variables. Almost every item on it exists only because your team owns the infrastructure underneath the application. The fewer knobs you personally manage, the fewer variables you'll ever need to isolate.

A Simple Production-only Bug

Consider this ASP.NET Core endpoint:

app.MapGet("/discount", () =>
{
    string region = Environment.GetEnvironmentVariable("REGION");

    if (region.ToLower() == "eu")
        return Results.Ok("20% discount");

    return Results.Ok("10% discount");
});

Everything works perfectly during development.

Then customers begin reporting HTTP 500 errors in production.

Eventually the logs reveal this exception:

NullReferenceException

The issue isn't difficult once you know where to look.

The production deployment forgot to define the REGION environment variable. Calling ToLower() on a null value immediately crashes the request.

The fix is straightforward:

string region = Environment.GetEnvironmentVariable("REGION") ?? "US";

if (region.Equals("EU", StringComparison.OrdinalIgnoreCase))
    return Results.Ok("20% discount");

The lesson isn't just about null checking. It's about understanding that production-only bugs are frequently caused by configuration differences rather than faulty business logic.

Without useful logs, developers might spend hours reviewing application code while completely overlooking the deployment configuration.

And step back one level further: this entire class of bug exists because a human had to remember to set a variable on a machine. Configuration drift isn't a coding failure, it's an operational failure, and it's the direct product of managing deployment configuration by hand.

When you find yourself writing runbooks to remind people which variables to set on which servers, that's another "why are we still doing this ourselves?" moment worth taking seriously.

Verify the Deployment Itself

Not every production issue originates from your source code.

Deployment problems are surprisingly common.

• A container image may not have been updated.

• A configuration file might be missing.

• A database migration may have failed.

• An environment variable could contain an incorrect value.

• A required secret may not have been deployed.

• A rollback might have restored an older application version without anyone noticing.

Before assuming your code contains a bug, confirm that production is actually running the version you intended to deploy.

Many incidents have been resolved simply by discovering that the wrong build was running.

Every single one of those production failures is a failure of infrastructure process, not of programming. They happen in homegrown deployment pipelines because homegrown pipelines have exactly as much verification as someone found time to build.

If your team can't answer "what version is running right now?" in one glance, your deployment system is generating bugs for you to debug later.

Do You Actually Need a PaaS?

Before we look at how a PaaS changes debugging, an honest question deserves an honest answer: does every team need one?

No. A PaaS is a trade. You hand over infrastructure control and pay a platform premium, and in exchange you stop spending engineering time on servers, pipelines, and observability plumbing. Whether that trade is worth it depends on your situation, and there are legitimate reasons to stay off a platform:

• You have unusual infrastructure requirements: GPU workloads, custom kernels, exotic networking, or software that needs specific hardware may simply not fit a platform's constraints.

• Compliance or data residency rules demand full control: Some regulated industries need to dictate exactly where and how everything runs.

• You operate at a scale where the economics flip: For very large workloads, the per-resource premium of a PaaS can exceed the cost of a dedicated platform team. That's why companies at massive scale build internal platforms, though note what they build: essentially their own PaaS.

• Infrastructure is your product: If you sell hosting, networking, or infrastructure tooling, operating it yourself is the business.

For everyone else, the evaluation comes down to a few questions worth asking:

• When production breaks, how much of the first hour goes to finding information versus acting on it?

• Is anyone on the team maintaining log pipelines, monitoring stacks, or deployment scripts as a side job on top of the product work they were hired for?

• Can you say, in one glance, exactly what version is running in production right now?

• When did you last lose a day to environment drift, like a bug caused by a server, config, or variable that didn't match?

If those answers make you wince, and for most small-to-medium product teams they do, you're paying the infrastructure tax without getting anything for it. The signal isn't your company's size, but where your engineering hours are going. A two-person startup and a fifty-person product team both come out ahead when nobody is babysitting servers.

And if you're currently unsure whether you need one, you probably do. Teams with a real reason to run their own infrastructure tend to know exactly what that reason is.

Why Debugging is Easier on a PaaS

The hardest part of diagnosing production bugs often isn't finding the root cause, it's finding the information you need to investigate.

In a traditional infrastructure setup, logs are scattered across multiple virtual machines, containers, load balancers, and background workers. When an application scales horizontally, a single customer request may touch several servers before it completes. Developers often spend more time SSHing into machines, locating log files, and correlating timestamps than actually debugging the problem.

That time is the infrastructure tax coming due. Every hour spent assembling evidence during an incident is an hour of downtime your team chose, months earlier, when it decided to own and operate all of that machinery itself.

A Platform as a Service (PaaS) changes that experience completely.

Instead of treating each server as an individual machine to manage, a PaaS treats your application as a single service. Logs from every instance are automatically aggregated into one place, metrics are collected continuously, and health checks are built into the platform. Whether your application is running on one container or fifty, you view it through a single dashboard instead of dozens of terminals.

When a production issue occurs, you can immediately answer important questions.

• Did the problem begin after the latest deployment?

• Is every application instance failing or only one?

• Did CPU or memory usage spike before the application crashed?

• Which release introduced the regression?

Instead of collecting this information manually, the platform already has it available.

Many PaaS tools also maintain deployment history, making it easy to compare application behavior before and after each release. If error rates suddenly increase after version 2.8.1 is deployed, the relationship becomes obvious. Rolling back to a previous deployment often takes only a few minutes, dramatically reducing downtime.

Infrastructure consistency is another major advantage.

Applications deployed through a PaaS are created from the same deployment configuration every time. Developers don't have to wonder whether one server has an outdated runtime, a missing dependency, an incorrect operating system package, or a forgotten environment variable. Consistent environments eliminate an entire category of production-only bugs before they happen.

Remember the REGION bug from earlier? On a platform where configuration is declared once and applied everywhere, that bug never ships.

Perhaps the biggest benefit is faster incident response.

During an outage, engineering teams shouldn't waste valuable time gathering evidence from multiple systems. Centralized logging, built-in monitoring, distributed tracing, deployment history, and health checks allow them to begin investigating immediately.

That translates directly into a lower Mean Time to Resolution (MTTR), shorter outages, and a better experience for both developers and customers.

Build Applications That Are Easy to Debug

Production bugs are inevitable. Complex systems fail in unexpected ways, no matter how experienced the engineering team is.

The difference between mature engineering organizations and everyone else isn't whether bugs occur. It's how quickly they can understand and resolve them.

Write meaningful logs that provide context instead of generic error messages. Collect metrics continuously so performance trends are visible before users complain. Instrument your applications with distributed tracing so requests can be followed across services. Keep staging environments as close to production as possible, and treat infrastructure configuration as carefully as application code.

Just as importantly, choose a platform that makes debugging easier instead of harder.

Teams relying on manually managed servers often spend the first hour of an incident simply gathering logs and connecting to machines. Teams running on a modern PaaS begin with the evidence already in front of them. They can correlate deployments with error spikes, inspect logs from every application instance, review infrastructure metrics, and trace failing requests without leaving a single dashboard.

Be honest about which team yours is. If your engineers maintain log pipelines, monitoring stacks, staging parity, and deployment scripts on top of the product they were hired to build, you're paying the infrastructure tax in its most expensive currency: incident time. Unless operating infrastructure is your business, it's overhead that you can hand to a platform.

A PaaS won't prevent every production bug, but it removes much of the operational complexity that makes those bugs difficult to diagnose. That means less time hunting for information, faster root-cause analysis, quicker recovery during incidents, and more time focused on building software instead of managing infrastructure.

When the next production issue appears, and it inevitably will, you'll spend less time asking, "Why can't I reproduce this?" and more time asking the better question: "Why were we ever doing all of this ourselves?"

Hope you enjoyed this article. You can connect with me on LinkedIn.

The phrase has become a running joke in software, but it's rarely funny when it happens in production.

A feature passes every local test, the pull request gets approved, the deployment finishes successfully, and then users start reporting failures.

On-call engineers get paged. Incident channels fill up. A fix that took ten minutes to write takes four hours to trace back to a missing environment variable or a runtime version mismatch nobody noticed.

The strange part is that this still happens in 2026.

Modern development has better tooling than ever. Containers, automated testing, cloud infrastructure, CI/CD pipelines, infrastructure as code, and AI coding assistants have all made building software considerably faster.

And yet engineering teams running customer-facing applications continue to lose significant time chasing bugs that only appear outside a developer's laptop.

One industry survey found that developers spend roughly 40% of their time on tasks unrelated to writing features,  and environment debugging is a leading culprit.

The reason isn't that engineers are careless. Most software doesn't fail because of bad code. It fails because code runs inside an environment, and those environments are rarely identical.

The gap between a developer's laptop and a production cluster is still one of the most consistent sources of engineering waste these days.

The real question is no longer why this problem exists. Every experienced engineering team understands environment drift. The better question is why so many product teams are still spending engineering time managing it.

What We'll Cover:

• Every Machine Tells a Slightly Different Story

• Dependencies Are Moving Targets

• Configuration Causes More Incidents Than Code Does

• The Real Cost of Managing Multiple Environments

• Why Are Teams Still Managing This Themselves in 2026?

• Local Success Doesn't Reflect Production Conditions

• Why Are More Engineering Teams Choosing Managed Platforms?

• What a Basic PaaS Setup Actually Looks Like

• Consistency is an Ownership Question, Not a Tooling Question

Every Machine Tells a Slightly Different Story

A production application depends on much more than source code.

It depends on the operating system, runtime versions, environment variables, databases, third-party services, networking rules, file permissions, installed libraries, and CPU architecture.

A developer running Node.js 24 LTS may be pairing with a teammate still on 22. One laptop has a newer OpenSSL version installed as a transitive dependency update. Another has a cached build artefact from three months ago that quietly changed behaviour after a library patch.

None of these differences looks significant on their own. Together, they create a local environment that behaves differently from every other environment in the pipeline.

This is how a test suite passes green on a developer's machine and fails in CI twenty minutes later. It's how an application boots cleanly on macOS but crashes on the Debian container your cloud provider runs.

It's why a microservice that handled 500 requests per second last Tuesday starts timing out this Monday after what appeared to be an unrelated dependency bump.

The code hasn't changed. The environment has.

Dependencies Are Moving Targets

Package managers have made software development productive, but they've also dramatically increased the surface area of a running application.

A typical Node.js web application today has between 500 and 1,500 packages in its dependency tree, including indirect dependencies, even when a developer explicitly installs only a handful.

A Python service using common data processing and web frameworks can pull in 200 to 400 packages. Most engineers have no direct relationship with the vast majority of packages their application ships.

When dependency versions aren't locked correctly, two developers installing the same project on the same day can receive materially different software stacks. Lock files like package-lock.json, pnpm-lock.yaml, poetry.lock, Cargo.lock exist precisely to prevent this, and they help. But they're one layer of control in a much larger consistency problem.

Runtime versions still differ. System libraries still differ. Base OS images in containers drift across patch cycles. A Docker image built from node:22 today isn't the same image that gets built in six weeks when the upstream tag has been updated. Teams that don't pin their base images precisely are unknowingly accepting environment drift at the foundation of every deployment.

Configuration Causes More Incidents Than Code Does

Many of the most disruptive production incidents on engineering teams have nothing to do with programming logic.

They come from configuration.

An environment variable is missing in the new deployment target. A database connection string points to staging instead of production. A feature flag is set to true in the developer's .env file but defaults to false in the deployed service, silently disabling a critical code path. An API key was rotated but the secret manager reference was updated in one environment and not the other.

These mistakes are common, and genuinely difficult to prevent, because configuration lives outside the application. It's managed separately, documented inconsistently, and almost never covered by standard test suites.

Post-incident reviews regularly surface configuration drift as the root cause of outages that took hours to diagnose because the application code looked completely correct.

The problem compounds across environments. A team running development, staging, pre-production, and production has four separate configuration states to keep aligned.

When an engineer adds a new environment variable, that change has to propagate through every environment reliably. In practice, it often doesn't. One environment gets missed. An old value lingers. The application behaves differently, and the investigation starts from scratch.

The Real Cost of Managing Multiple Environments

Engineering leadership often underestimates how much time is consumed by environment management, not because it's hard to observe, but because it's distributed across dozens of small tasks that never appear as line items.

Someone updates the Node runtime in the base Docker image and spends an afternoon chasing a downstream test failure that turned out to be a transitive dependency incompatibility.

Someone provisions a new staging environment and spends a day replicating the production configuration by hand. Someone rotates credentials, misses one service, and triggers a silent failure that takes until the next deployment cycle to surface. Someone joins the team and spends the first two days getting a local environment running instead of shipping work.

Estimates from engineering productivity research suggest that infrastructure and environment-related tasks consume between 15 - 25% of total engineering capacity at companies that own their own deployment infrastructure. For a team of ten engineers, that's effectively two to three people running hard and producing no customer-facing output.

This is the cost that doesn't appear on sprint boards. It lives in Slack threads, in incident retrospectives, and in the quiet acknowledgement that the team is slower than it should be.

None of this work appears on a roadmap. Customers never ask for it. It doesn’t create differentiation. Yet product teams spend hundreds of engineering hours every year maintaining consistency between environments simply to keep software deployable. Environment drift isn't just a reliability problem. It's an engineering capacity problem.

Why Are Teams Still Managing This Themselves in 2026?

Given all of this, the reasonable question is why so many engineering teams are still owning this complexity directly.

Part of the answer is inertia. Teams that built their infrastructure several years ago, when Kubernetes was the obvious answer to every scaling question and "we control our own stack" felt like a competitive advantage, now maintain that infrastructure because changing it has a cost.

The investment is already made. The tooling is already familiar. The pain is distributed and chronic rather than acute, which makes it easier to absorb than to address.

Part of the answer is organisational habit. Hiring a platform or DevOps engineer to manage infrastructure feels like the right response to environmental problems. But that engineer becomes responsible for maintaining the consistency layer indefinitely. Patching base images, updating runtime versions, managing certificate renewals, and debugging networking issues across environments, rather than delivering product leverage.

Part of the answer is a belief that more control produces better outcomes. Running your own infrastructure gives complete visibility into every configuration decision.

But complete control also means complete responsibility. Every decision the platform team makes is a decision the platform team must maintain, document, and revisit every time something upstream changes.

Most product engineering teams aren't in the infrastructure business. They're in the business of building software for customers, and every hour spent on environment consistency is an hour not spent on that.

The honest answer is that many teams are managing this complexity themselves because they haven't yet found a clear path to stopping.

Local Success Doesn't Reflect Production Conditions

One consistent failure mode is treating a passing local test as a signal that a deployment is safe.

Production environments impose conditions that development machines never encounter. A service that starts cleanly on a laptop with no concurrent users will behave differently when handling 2,000 requests per second with three application instances competing for a shared database connection pool.

A background job that completes in milliseconds locally may time out in production when it runs simultaneously with twelve other jobs against a database under real write load.

Staging environments exist to surface these differences before they reach users. But staging only provides value when it actually resembles production, like the same infrastructure, the same runtime versions, the same configuration shape, same network topology.

Many teams treat staging as a best-effort approximation. Over time, configuration drift between staging and production means that staging stops catching the failures it was designed to catch. Teams end up discovering environment-related issues in production anyway, which is the worst place to find them.

Maintaining genuine parity across three or four environments is expensive and requires continuous attention. Infrastructure updates must be applied uniformly. Runtime versions must stay synchronised. Configuration must be propagated reliably.

Without active discipline, staging drifts away from production, and the safety net disappears.

Why Are More Engineering Teams Choosing Managed Platforms?

At some point, every engineering organisation has to ask a more fundamental question. Should we keep investing engineering time into maintaining environments, or should we move that responsibility to a platform built for it?

This is the context in which Platform as a Service has become a more serious consideration for teams that previously managed their own infrastructure.

A well-designed PaaS doesn't remove engineering responsibility. It relocates it.

Developers still write code. They still define environment variables and build processes. They still decide what their application needs. The difference is that the platform provides a consistent, maintained runtime across every environment like development, staging, and production, without the team owning the underlying infrastructure.

The same application definition runs everywhere. Environment parity becomes a property of the platform rather than a discipline the team has to enforce continuously.

This matters most to engineering teams with real deployment velocity, the teams shipping multiple times per day, running several services, and operating with the expectation that deployments are predictable.

When the platform standardises the environment, deployments stop being experiments. Engineers stop discovering production-only failures at the worst possible time.

The operational tradeoff is real. Some organisations require control over their infrastructure for compliance, regulatory, or architectural reasons that a PaaS can't accommodate. But many teams that believe they need that control have never closely examined the cost of maintaining it.

The question isn't whether owning infrastructure gives you control. It's whether that control is producing outcomes that justify the engineering capacity it consumes.

What a Basic PaaS Setup Actually Looks Like

The argument for a managed platform is easier to evaluate with a concrete picture of what adopting one involves. The details vary across providers like Render, Railway, Sevalla, etc, but the setup's shape is remarkably consistent and smaller than most teams expect.

Step 1: Connect your repository. Every mainstream PaaS starts from your Git repository. You authorise the platform against GitHub or GitLab, point it at a repo, and choose a branch to deploy from. From that moment, the platform watches for pushes. There's no CI pipeline to write for the basic case, since build-and-deploy on push is the default behaviour.

Step 2: Define the application, once, in a file. Instead of configuring servers, you describe what your application is: the runtime, the build command, the start command, and the services it needs. Most platforms let you do this through a dashboard, but the better practice is a declarative file that lives in the repo.

services:
  - type: web
    name: my-api
    runtime: node
    buildCommand: npm ci
    startCommand: npm run start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: my-api-db
          property: connectionString
      - key: NODE_ENV
        value: production

databases:
  - name: my-api-db
    plan: basic

This file is the payoff of the whole model. It's the single source of truth for how the application runs, it's version-controlled alongside the code, and, critically, it's the same definition in every environment.

The drift described earlier in this article, where staging quietly diverges from production, has nowhere to live, because there is no second copy of the environment to fall out of sync.

Step 3: Set your environment variables in the platform, not in files. Secrets and configuration move out of scattered .env files and into the platform's environment settings, scoped per environment.

When an engineer adds a new variable, the platform surfaces it in one place rather than requiring a manual update across four deployment targets. Most platforms also support environment groups, so shared configuration is defined once and inherited.

Step 4: Attach managed services. Databases, caches, and cron jobs are provisioned by the platform rather than installed and patched by your team.

In the example above, the database is declared in the same file as the application, and its connection string is injected automatically, so there's no connection string to copy incorrectly into staging.

Step 5: Push, and let preview environments do the rest. This is where the parity argument becomes tangible. Most modern PaaS providers spin up a preview environment for every pull request: a full, disposable copy of the application, built from the same definition file, running on the same infrastructure as production.

"Works on my machine" stops being the standard of evidence, because every reviewer is looking at the code running in a production-shaped environment before it merges. When the PR closes, the environment is destroyed.

That's the whole setup. For a typical web service, going from repository to a deployed, auto-updating application with a managed database takes an afternoon, not a quarter.

For teams with existing infrastructure, the sensible starting point isn't a migration project. It's one service , ideally something low-risk and self-contained, like an internal tool or a background worker.

Run it on a platform for a month, compare the operational load against its Kubernetes-hosted siblings, and let the result inform the larger decision. Most teams that make this comparison discover the question isn't whether the platform can handle their workload. It's how much of their engineering week they'd been spending to get a worse version of the same guarantee.

Consistency is an Ownership Question, Not a Tooling Question

"It worked on my machine" gets framed as a process problem, or a testing problem, or occasionally a culture problem. The real framing is more useful: it's an ownership problem.

Every difference between environments like runtime versions, dependency trees, configuration values, and infrastructure state increases the probability that software behaves unexpectedly in production. The conventional response is to invest in better tooling: stricter lock files, more comprehensive CI, better container discipline, more thorough staging.

All of these reduce the problem. None of them eliminates the underlying dynamic, which is that the team is responsible for the consistency of every environment it owns.

The teams that have largely solved deployment reliability in 2026 aren't necessarily the ones with the most sophisticated infrastructure. Many of them are the ones that have reduced the number of environments they own and maintain.

They have moved infrastructure decisions to platforms designed to handle them, and redirected that engineering capacity toward problems that are actually differentiated: the product, the performance, the reliability of the application itself.

Environment consistency is a solvable problem. The remaining question is ownership. Every product team must decide whether maintaining infrastructure is part of its competitive advantage or simply an operational burden it has accepted over time. More engineering teams are concluding that their advantage comes from shipping product, not managing environments.

During a quarterly planning session, one of our engineers asked a question nobody on the team had thought to ask directly before: “How much of our time is actually going into infrastructure, versus building things people use?”

It wasn’t a rhetorical question. We pulled up our sprint history, our incident logs, and our calendars, and tried to answer it honestly.

We were a 7-person internal tooling team inside a larger enterprise organisation. Our mandate was straightforward: make other teams across the company faster through workflow automation, internal dashboards, and integrations between internal systems.

Our Amazon Web Services (AWS) environment wasn’t poorly built. It was, by most standards, mature infrastructure. Containerised services on ECS, automated deployments through GitHub Actions, CloudWatch observability, and properly scoped IAM roles across environments. Nothing about it would have raised concerns in an architecture review.

What it cost us wasn’t visible on an invoice. It was visible in calendars, in context-switching, and in how often “infrastructure work” quietly displaced the backlog we were actually accountable for.

That conversation eventually led us to evaluate and migrate to Sevalla, a Platform-as-a-Service infrastructure control for operational simplicity. The migration took three weeks. The effects were measurable within a month.

In this article, we'll walk through what our AWS setup looked like before migrating, what the migration process actually involved, the specific metrics that changed afterwards, and the trade-offs we accepted along the way.

What We'll Cover:

• Before the Migration

• The Number That Started the Conversation

• The Deployment Process: What “Reasonably Automated” Actually Meant

• What the Migration Actually Involved

• What Changed After the Migration

  • Deployment time dropped from ~12 minutes to ~3 minutes

  • Any engineer could deploy confidently on day one

  • Rollbacks went from a 12-minute manual process to a 30-second action

  • Infrastructure maintenance time dropped to approximately 2–3 hours per week

  • Log visibility improved without any additional tooling

• What We Gave Up

• The Actual Lesson

Before the Migration

Our AWS setup was respectable. We weren’t running something embarrassingly manual. We had:

• ECS for container orchestration

• RDS for databases

• CloudWatch for logs and metrics

• A CI/CD pipeline through GitHub Actions

• IAM roles managed across environments

• CloudFormation templates maintained by one senior engineer

It worked. Deployments were automated. The system was stable.

The problem wasn’t that anything was broken. The problem was what it cost us to keep it running smoothly.

The Number That Started the Conversation

During a quarterly planning session, we tried to honestly account for where engineering time was going.

We estimated that across the team, roughly 12–15 hours per week were being spent on infrastructure-related work that wasn’t directly delivering value to internal users. This included:

• Deployment pipeline maintenance and debugging (~4 hrs/week)

• CloudWatch log investigation and alert tuning (~3 hrs/week)

• IAM permissions management and access reviews (~2 hrs/week)

• Dependency updates, security patches for infrastructure components (~2 hrs/week)

• Ad hoc incidents, environment drift, cost anomaly investigations (~3–4 hrs/week)

At a fully-loaded engineer cost, 12–15 hours per week is the equivalent of roughly one-third of a full-time engineer, every week, spent on keeping the lights on rather than building anything.

For a team whose backlog was already longer than we could realistically tackle, that number was hard to justify.

The Deployment Process: What “Reasonably Automated” Actually Meant

Our deployment pipeline was good by most standards. Push to main, GitHub Actions triggered a build, pushed an image to ECR, and updated the ECS service. On a good day, a deployment took about 12 minutes from merge to live.

But “reasonably automated” came with caveats.

Only one engineer fully understood the pipeline. If something failed mid-deployment, like a task definition mismatch, an IAM permission error, or a CloudFormation stack conflict, most of the team would either wait for that engineer or spend significant time reading AWS documentation to diagnose it themselves.

Rollbacks were manual. There was no clean one-click rollback. Rolling back meant redeploying the previous image tag, which required knowing what that tag was, triggering the pipeline again, and waiting another 12 minutes. In an incident, those 12 minutes mattered.

Environment parity was fragile. We had staging and production environments. Keeping them consistent required discipline and periodic reconciliation. Configuration drift happened more than we’d like to admit, and it occasionally caused releases to behave differently in production than they had in staging.

New team members couldn’t deploy confidently. Onboarding a new engineer to the deployment process took the better part of a day, and most new hires remained hesitant to trigger deployments independently for weeks. The pipeline was automated, but the knowledge wasn’t.

What the Migration Actually Involved

We moved over the course of about three weeks, migrating services incrementally rather than cutting over all at once.

The largest time investment was translating our environment variable configuration and secrets management from AWS Parameter Store into Sevalla’s environment configuration. That took roughly half a day.

The CI/CD migration was straightforward. We replaced our ECS deployment step with Sevalla’s Git-connected deployment. The GitHub integration picked up our repository directly.

Database migration was the most careful part. We ran both databases in parallel for two weeks, verified data consistency, then cut over DNS. There was no data loss, and no downtime.

Total migration effort across the team: approximately 40 hours spread over three weeks, mostly concentrated in two engineers.

What Changed After the Migration

Deployment time dropped from ~12 minutes to ~3 minutes

This wasn’t the most important change, but it was the most immediately visible one. Faster deployments meant faster feedback loops. A fix could be in production and verified within minutes rather than waiting out a build cycle.

Over a typical week with 8–10 deployments, that’s roughly 90 minutes of cumulative waiting time recovered, per week.

Any engineer could deploy confidently on day one

This was the change that mattered most operationally. The deployment process became visible, documented by the interface itself, and required no specialist knowledge to operate. A new engineer joining the team could deploy their first change independently on their first day.

The informal “deployment gatekeeper” role that had quietly formed around our most AWS-experienced engineer effectively dissolved.

Rollbacks went from a 12-minute manual process to a 30-second action

Every deployment in Sevalla retains a one-click rollback to the previous build. During the first month after migration, we used this twice: once for a regression we caught quickly, and once during a failed database migration we immediately needed to reverse.

Both incidents that previously would have required hours of manual intervention were resolved in under a minute.

Infrastructure maintenance time dropped to approximately 2–3 hours per week

We no longer maintain IAM roles, CloudWatch alerts, CloudFormation templates, or ECS task definitions. The infrastructure surface area we own shrank dramatically.

Our estimate of 12–15 hours per week of infrastructure work fell to roughly 2–3 hours per week . It now involves  primarily monitoring application behaviour and reviewing build logs. That’s a recovery of approximately 10 hours per week of engineering time redirected toward the actual backlog.

Over a quarter, that’s roughly 130 hours, or about three full working weeks, returned to product work.

Looking back, we had quietly become a platform team. Not because we intended to, but because every infrastructure decision created more infrastructure to own.

Log visibility improved without any additional tooling

One outcome we didn’t anticipate: production visibility got better even though we invested less in it.

On AWS, meaningful log analysis required CloudWatch Insights queries, proper log group configuration, and knowing where to look. Useful observability required deliberate setup effort.

On Sevalla, build logs, runtime logs, and deployment history are accessible directly from the dashboard without configuration. When something went wrong in production, the time from “something is broken” to “here is what happened” dropped from 10–20 minutes of searching across tools to under 2 minutes in most cases.

What We Gave Up

Intellectual honesty requires listing the trade-offs.

First, we have less infrastructure flexibility. If we needed custom networking topology, specialised compute instances, or fine-grained storage configuration, Sevalla wouldn't cover those requirements. For an internal tooling team, none of those needs has materialised. But they could.

Also, some AWS-native integrations required reworking. We used a few Lambda functions that had to be refactored into services. That added some migration complexity we hadn’t fully anticipated.

The Actual Lesson

The migration confirmed something that’s easy to miss when you’re inside it: the cost of infrastructure ownership for a product team isn’t primarily the cloud bill. It’s the engineering attention.

For our team, 10 hours per week of recovered time across a 7-person team meant a 28% increase in capacity available for work that users actually care about. That’s not a marginal improvement. It’s a meaningful change in what the team can realistically ship.

That outcome isn’t specific to Sevalla. Any infrastructure simplification that genuinely reduces operational burden would produce a similar result.

The question worth asking isn’t whether your team can manage infrastructure. It’s whether managing infrastructure is the best use of the engineering capacity you have.

For an internal tooling team whose value is measured entirely by what it ships, not by how it deploys, the answer, for us, was clearly no.

Roadmaps talk about velocity. Leadership meetings talk about reducing cycle time. Quarterly goals talk about faster execution and quicker releases.

Every business wants teams moving faster.

Then many of those same companies make a decision that quietly slows everything down. They optimise for infrastructure flexibility instead of product delivery.

It sounds reasonable in the beginning. Teams want control. Engineers want options. Platform architects want systems that can support every future scenario.

So production teams start building infrastructure ecosystems around themselves.

Deployment pipelines get built from scratch. Cloud resources become heavily customised. Internal platforms gain endless knobs, switches, and configuration layers. New projects begin with architecture discussions instead of customer problems.

Months later, software delivery slows down.

Product teams miss timelines. Releases move out by quarters. Customer feedback arrives later. Competitors keep shipping.

The tradeoff hiding underneath all of this is simple. Teams choose flexibility over actually shipping.

And beyond a certain point, flexibility becomes one of the most expensive forms of organisational drag a company can create.

What We'll Cover:

• The Myth That More Flexibility Creates Better Production Systems

• Infrastructure Ownership Quietly Becomes a Second Business

• The Real Cost Is Delayed Customer Learning

• PaaS Changes the Optimisation Function

• The Best Production Teams Remove Decisions

• Custom Infrastructure Usually Solves Problems Nobody Has Yet

• The Real Competitive Advantage Is Shipping Faster

• When PaaS Might Not Be the Right Choice

• Stop Building Infrastructure Businesses By Accident

The Myth That More Flexibility Creates Better Production Systems

Engineering teams love optionality. The logic sounds convincing.

If infrastructure is fully customizable, teams can adapt to future requirements. If deployment systems are built internally, every use case can be supported. If every layer is configurable, engineers can optimise for unique situations.

This feels like responsible engineering. But it often becomes expensive business behaviour.

Most production teams massively overestimate how often they need deep infrastructure flexibility.

What actually happens becomes predictable.

A product team starts a new initiative. Instead of shipping an early version and learning from customers, discussions begin.

• Should Kubernetes clusters be organised by team or service?

• Should CI/CD use GitHub Actions or Jenkins?

• Should secrets management use Vault or cloud-native tooling?

• Should observability use Prometheus or Datadog?

• Should deployment strategies use canary releases, blue-green deployments, or something custom?

Weeks disappear. No customer sees anything. No assumptions get tested. No learning happens.

Meanwhile, product managers wait. Leadership waits. Customers wait.

Even with agentic coding tools like Claude generating code, scaffolding systems and accelerating implementation, teams still lose speed when every output collides with infrastructure decisions and deployment debates.

The problem isn't technology. The problem is optimising around theoretical future flexibility instead of present business outcomes.

Software creates value when customers use it. Everything else is support work.

Infrastructure Ownership Quietly Becomes a Second Business

Traditional deployment models accidentally create a dangerous pattern: companies think they are building products. Slowly, they start building infrastructure organisations.

Production teams provision servers. Then networking. Then IAM systems. Then deployment pipelines. Then, observability layers. Then secrets management. Then autoscaling. Then rollback systems.

Every decision feels reasonable in isolation. But collectively, teams create an operational machine they now own forever.

And ownership is where the hidden cost appears.

Because infrastructure work doesn't end after launch. It expands. Pipelines need maintenance. Security policies change. Monitoring systems require tuning. Platform dependencies break. Internal tooling needs upgrades.

Production teams gradually spend more time maintaining systems around software than improving software itself.

This creates a strange situation: highly paid engineers become caretakers for infrastructure instead of builders of customer value.

No customer purchases a product because deployment pipelines have become elegant. No customer upgrades because IAM policies are beautifully designed. No competitor loses market share because Kubernetes YAML looks sophisticated.

Customers care about products solving problems. Infrastructure only matters when it slows product delivery.

And infrastructure ownership creates endless opportunities for that to happen.

The Real Cost Is Delayed Customer Learning

The biggest cost of infrastructure complexity isn't engineering effort. It's delayed learning.

Software companies win through feedback loops. Teams ship something. Customers react. Teams learn. Products improve.

The faster this cycle operates, the stronger the company becomes.

Infrastructure work interrupts that loop. Every month spent building deployment systems is a month where customers aren't using new features. Every quarter spent designing internal platforms delays customer feedback. Every architecture discussion delays real market signals.

This is where many organisations misunderstand velocity.

They look at sprint metrics. They measure tickets completed. They count engineering output.

But business speed isn't measured through internal activity. Business speed measures how quickly ideas become customer reality.

Infrastructure ownership slows that process dramatically. And slower learning creates slower companies.

PaaS Changes the Optimisation Function

This is where Platform as a Service changes the equation.

PaaS forces organisations to optimise around shipping rather than infrastructure ownership. That shift matters more than most teams realise.

Instead of spending weeks designing deployment architecture, production teams connect repositories and deploy.

Instead of building pipelines manually, pipelines already exist.

Instead of designing scaling systems, scaling becomes infrastructure behaviour rather than engineering work.

Instead of repeatedly building foundations, infrastructure becomes a utility.

That sounds simple. It should be simple. Deployment should feel boring. But the fact that deployment often becomes a major organisational project is usually evidence of unnecessary complexity rather than unavoidable complexity.

PaaS providers remove entire categories of decisions. And while many engineers see that as a compromise, it's often the opposite.

Constraints create speed. Speed creates learning. Learning creates better products.

The Best Production Teams Remove Decisions

There's a common misconception that elite engineering organisations maximise options. The opposite is often true.

High-performing production teams aggressively eliminate decisions. They standardise. They create defaults. They remove unnecessary choices.

Because every decision carries a cost.

Cognitive load grows. Coordination increases. Meetings multiply. Dependencies expand. Eventually, the workaround software becomes larger than the software itself.

PaaS systems follow a different philosophy. They intentionally reduce optionality.

That reduction creates focus. And focus creates product velocity. Product velocity creates business outcomes.

The chain is straightforward. Too many organisations break it by introducing infrastructure ownership far too early.

Custom Infrastructure Usually Solves Problems Nobody Has Yet

One of the most expensive habits in software companies is solving future problems before current ones exist.

Teams build for scale before scale exists. They create multi-region architectures before international users arrive. They build deployment frameworks before deployment pain appears.

This usually comes from good intentions. Engineers want to avoid future rewrites. But the irony is that premature flexibility creates an immediate business slowdown.

A startup with twenty engineers shouldn't operate like a company with ten thousand engineers. Yet many production teams copy infrastructure patterns from giant technology firms.

What gets ignored is context. Large technology companies have entire platform teams maintaining internal systems. They have thousands of engineers supporting infrastructure investments.

Most companies do not.

Copying technical architecture without copying organisational scale creates enormous inefficiency.

PaaS acts as protection against this behaviour. It prevents teams from accidentally becoming infrastructure companies before they become successful product companies.

The Real Competitive Advantage Is Shipping Faster

Companies rarely lose because infrastructure flexibility was insufficient. They lost because competitors learned faster.

Speed matters. Not speed in sprint or linear dashboards. Not speed in story points.

Actual speed. The ability to move ideas into production quickly. The ability to test assumptions rapidly. The ability to learn continuously.

Shipping creates learning. Learning creates improvement. Improvement creates advantage.

Infrastructure complexity interrupts this loop. PaaS strengthens it.

This is why deployment decisions should never be treated as purely technical discussions. They are business decisions.

Infrastructure ownership affects company velocity. Velocity affects market outcomes.

The argument isn't about servers. The argument is about competitive speed.

When PaaS Might Not Be the Right Choice

There are situations where PaaS can become limiting.

Organisations with highly specialised infrastructure requirements may require direct control over networking, security layers, hardware optimisation, or deployment behaviour.

Some industries have regulatory requirements that create unusually specific infrastructure needs.

Large organisations with mature platform engineering teams may also justify custom infrastructure investments.

There are also cases where platform costs become meaningful at very large scale.

These scenarios exist. But many companies use edge cases as justification years before they become relevant. They prepare for infrastructure problems they may never have while struggling to ship ordinary product releases today.

That sequence creates unnecessary friction.

Stop Building Infrastructure Businesses By Accident

Engineering culture often celebrates flexibility.

Flexibility sounds sophisticated. It sounds future-proof. It sounds like good systems thinking.

But flexibility carries a cost. Every additional option creates complexity. Every additional decision slows movement. Every additional layer creates maintenance work.

Production teams should ask a simpler question. Does this help us ship customer-facing software faster? If the answer is no, it deserves scrutiny.

Too many companies accidentally build infrastructure ecosystems that optimise for hypothetical future needs.

Meanwhile, competitors deploy products, learn from customers and improve faster.

Shipping beats flexibility. And for many production teams, choosing a PaaS is one of the clearest ways to prove it.

Hope you enjoyed this article. You can connect with me on LinkedIn.

Then the real work starts. Infrastructure must be provisioned. CI/CD pipelines need to be set up. Secrets require management. Monitoring needs wiring. Databases need deployment. Logging needs configuration. Security policies need implementation. Networking rules need review.

Weeks disappear before users see anything useful. Many organizations treat this as normal. They call it engineering rigour. They assume this operational setup phase is simply part of software development.

It is not.

For teams already running production systems, rebuilding infrastructure foundations for every new project is organizational waste. It is repetitive operational labour disguised as an engineering discipline.

The uncomfortable question is not, “How can we do this setup faster?” The real question is: why are we still doing it ourselves at all?

This is where Platform as a Service changes the conversation. A good PaaS shifts the starting point from “rebuild the foundations” to “start shipping. Because new projects should begin closer to customer value, not closer to infrastructure assembly.

In this article, we'll look at why many production teams waste time rebuilding the same infrastructure for every new project, how PaaS helps remove that work, and why engineering teams should question if managing complex infrastructure still makes sense for most projects.

What We'll Cover:

• Most Teams Were Not Hired to Build Infrastructure

• AWS Primitives Are Not a Competitive Advantage

• Most Teams Should Not Be Managing Kubernetes

• PaaS Changes the Starting Point

• Repetition Creates Hidden Organizational Waste

• Standardization Is Usually Faster Than Flexibility

• Platform Teams Become Multipliers

• Easier Starts Create More Innovation

• When Specialized Control Actually Matters

• Starting From Zero Is a Process Failure

Most Teams Were Not Hired to Build Infrastructure

Software teams exist to solve business problems. Customers do not care whether Kubernetes manifests were structured elegantly. They do not admire carefully designed Terraform modules. They do not celebrate handcrafted networking policies.

Customers care about outcomes. They care about faster onboarding. Better recommendations. Smoother payments. Fewer bugs. Simpler workflows.

Yet many engineering organizations spend huge portions of time doing work customers never see.

Teams repeatedly create deployment pipelines. Configure environments. Manage certificates. Set up observability stacks. Tune infrastructure rules. Assemble cloud primitives.

Infrastructure matters. Reliability matters. Security matters.

The problem is duplication. If every project independently recreates the same operational systems, organizations keep rebuilding internal platforms over and over again without admitting it.

This behaviour has become so normalized that teams barely notice it anymore. But rebuilding the same foundation repeatedly is not operational maturity. It is inefficiency scaled across the organization.

AWS Primitives Are Not a Competitive Advantage

Many teams confuse cloud ownership with strategic advantage. Owning Kubernetes clusters does not create differentiation. Managing IAM rules does not create customer value. Writing infrastructure glue code does not strengthen market position.

These are implementation details. Yet many organizations spend extraordinary energy managing them as if they are core business assets.

Some teams effectively become part-time infrastructure companies without realizing it. Their engineers slowly accumulate operational responsibilities until maintaining systems consumes more effort than delivering products.

The outcome becomes predictable. Infrastructure expands. Operational complexity grows. Delivery speed declines. Nobody notices because the pain arrives gradually.

A team starts with one Kubernetes cluster. Then another environment appears. More deployment pipelines emerge. Additional tooling gets layered on top. Logging systems become fragmented. Monitoring evolves differently across products.

Eventually, teams spend increasing amounts of time maintaining systems they never intended to own.

Infrastructure ownership is often not a strategy. It is inertia.

Most Teams Should Not Be Managing Kubernetes

Kubernetes has become an engineering culture. It appears in architecture diagrams, conference talks, hiring requirements, and internal roadmaps. Its adoption often feels inevitable.

But normalization and necessity are not the same thing. Many organizations adopted Kubernetes because industry momentum made it seem like the default path. Not because they had workloads that required its complexity. But the result is predictable.

Small and medium teams end up managing orchestration systems designed for massive operational environments.

They maintain YAML configurations, networking layers, ingress systems, deployment strategies, and operational tooling stacks before delivering meaningful product value. This has become strangely accepted.

A ten-person engineering team maintaining infrastructure patterns designed for internet-scale organizations should raise serious questions. A small team pretending to be a platform team is an operational dysfunction.

Many companies adopt infrastructure complexity built for organizations operating at a vastly different scale. They inherit the burden without inheriting the benefits.

PaaS Changes the Starting Point

Traditional infrastructure approaches force teams to think from the bottom upward. Servers come first. Then operating systems. Then networking. Then deployment systems. Then monitoring. Eventually, applications arrive.

PaaS reverses this sequence. Developers begin with applications and business goals. The platform absorbs operational complexity.

Teams stop asking, “How do we provision resources?” They start asking, “What problem are we solving?” That sounds like a small shift. In practice, it changes everything.

A mature PaaS environment often provides deployment pipelines, integrated observability, databases, scaling behaviour, security controls, and operational standards before a team writes meaningful application logic.

Projects begin with product development rather than infrastructure construction. That dramatically changes time-to-value.

Repetition Creates Hidden Organizational Waste

Organizations often underestimate operational waste because repetitive work feels familiar. Setting up a deployment pipeline may consume only a few days. Configuring logging may feel routine. Creating security rules may seem manageable.

No individual task appears expensive. The cost appears when repetition scales.

If ten projects independently spend two weeks rebuilding nearly identical operational systems, months of engineering capacity disappear. Those engineers could have shipped customer capabilities. They could have reduced friction. They could have tested new ideas. Instead, they rebuilt plumbing.

Engineering teams understand leverage in nearly every other area. Nobody rewrites sorting algorithms for every application. Nobody recreates database engines from scratch. Nobody builds networking stacks repeatedly.

Reuse is accepted as basic engineering wisdom. Infrastructure should not receive special treatment. Build once. Reuse many times.

PaaS simply applies software engineering principles to operational systems.

Standardization Is Usually Faster Than Flexibility

Engineering teams often resist standardization because they fear losing control. Every project feels unique. Every system appears different. The desire for flexibility sounds reasonable.

But complete flexibility often creates operational chaos. Different teams deploy applications differently. Logging behaves inconsistently. Monitoring varies across systems. Security implementations drift.

Documentation fragments. Onboarding slows. Incident response becomes harder. Complexity quietly accumulates.

PaaS introduces constraints, and many engineers instinctively resist constraints. They should not. Useful constraints often increase speed.

Predictable deployment patterns reduce confusion. Shared monitoring standards simplify troubleshooting. Consistent environments reduce cognitive overhead.

Developers spend less energy understanding infrastructure differences and more time delivering product functionality.

Consistency compounds.

Platform Teams Become Multipliers

Many organizations interpret PaaS as buying a vendor product. That misses the bigger idea.

PaaS is fundamentally about creating reusable capabilities. Some organizations buy platforms. Others build internal platforms.

The principle remains the same.

A platform team creates systems once and allows everyone else to benefit. Instead of dozens of product teams independently solving operational problems, a dedicated group centralizes expertise and builds reusable solutions.

The effect becomes substantial. One deployment improvement accelerates every future release. One observability improvement strengthens every application. One security enhancement protects every team.

Platform teams create organizational leverage. Without this model, expertise stays fragmented. With it, expertise compounds.

Easier Starts Create More Innovation

Operational friction changes behaviour. When launching projects becomes expensive, organizations become cautious. Teams avoid experiments. Small ideas feel risky. Prototypes become difficult to justify.

Over time, innovation slows. Not because organizations lack ideas, but because starting became too expensive.

Teams running mature platforms understand this relationship. Reducing startup friction increases experimentation. Smaller projects become practical. Learning cycles become shorter.

New ideas appear more often because the cost of testing them falls dramatically. The easier it becomes to launch something, the more opportunities organizations create.

PaaS reduces startup friction. That reduction changes culture.

When Specialized Control Actually Matters

There are exceptions. Massive data platforms, highly specialized machine learning systems, and extremely customized environments may require lower-level infrastructure ownership.

Some workloads genuinely need deeper operational control. But these scenarios are exceptions, not defaults. Too many teams inherit infrastructure complexity designed for edge cases and treat it as standard practice.

Most production applications do not need custom orchestration layers. Most teams do not need to own Kubernetes. Most engineering groups do not need to spend weeks assembling infrastructure before shipping software.

The default assumption should be the opposite.

Starting From Zero Is a Process Failure

Many organizations normalize unnecessary operational drag. Long setup cycles become accepted. Infrastructure duplication becomes routine. Cloud complexity becomes expected.

Eventually, teams stop questioning it. They assume this is simply how engineering works. It is not.

If launching a new application requires weeks of foundational setup before customer value appears, that is not an engineering discipline.

The goal was never to become an infrastructure company. It was to ship software.

It's not about side projects, early-stage experiments, or a single-service app with low traffic.

This is for teams shipping real systems. Systems with users, uptime expectations, and release pressure.

Because at that stage, your deploy process is no longer a convenience. It's part of your product.

And right now, for most teams, it's the weakest part.

In this article, we'll look at why deployment complexity keeps growing as systems scale, how modern tooling unintentionally pushes teams into platform engineering work, and why many production teams are rethinking the infrastructure they manage themselves.

We'll also look at where Platform as a Service (PaaS) fits into this shift, what trade-offs it introduces, and when adopting one actually makes sense.

What We'll Cover:

• The Promise You Were Sold

• The Hidden Contract You Are Already Operating Under

• You Are Already Acting Like a Platform Team

• The Cost Is Not Complexity. It Is Time

• Why “It Works on My Machine” Still Exists

• Fragmentation Is the Root Problem

• This Model Breaks as You Scale

• The Shift Toward Platforms

• What You Stop Paying For

• From Infrastructure Work Back to Product Work

• Collapsing the Stack

• The Trade-Off You Are Actually Making

• When This Becomes Urgent

• What a “Simple Deploy” Actually Means

• Closing Thought

The Promise You Were Sold

Every modern stack makes the same promise: Shipping is easy. Deploying is automated. Infrastructure is abstracted away. Push your code. Watch it go live.

That promise works , until it doesn’t.

And when it breaks, it doesn't fail gracefully. It expands.

A “simple deploy” turns into a multi-day investigation across systems you never intended to own.

Not because your team is careless. Because the model itself assumes you'll take on more responsibility than it admits.

The Hidden Contract You Are Already Operating Under

When you deploy today, you're not just shipping code. You're agreeing to run a distributed system of tools.

You own the build pipeline, the container lifecycle, the runtime configuration, the network rules, the secrets layer, the scaling logic, and the observability stack.

Each of these is presented as a separate concern. In reality, they're tightly coupled.

And you're the only layer holding them together. That's the hidden contract.

You Are Already Acting Like a Platform Team

If your deploy process involves CI pipelines, container registries, cloud services, environment variables, and monitoring tools, you're not just an application team anymore. You're running a platform.

You're defining how code moves from commit to production. You're deciding how failures are handled. And you're shaping how services communicate.

That's platform engineering work.

The issue isn't that this work exists. The issue is that most teams take it on unintentionally, without the structure, tooling, or dedicated ownership a real platform team would require.

The Cost Is Not Complexity. It Is Time

It's easy to describe this problem as “complexity.” But that undersells it.

The real cost shows up in how your team spends its time.

Deploys that should take minutes stretch into hours. Then days. Engineers context-switch from product work into debugging CI caches, fixing misconfigured secrets, or tracing network failures across services.

Releases slow down. Not because your team can't build features, but because shipping them becomes unpredictable.

Onboarding gets harder. New engineers don't just learn the codebase. They have to learn your deployment system.

None of this appears on a roadmap. But it directly impacts how fast you can move.

Why “It Works on My Machine” Still Exists

We were supposed to have solved this: Containers. Infrastructure as code. Reproducible builds.

Yet the gap between local and production still shows up at the worst possible moment.

Because the problem was never just environment parity. It's system parity.

Your local setup doesn't include the same limits, permissions, network paths, or scaling behavior as production.

Those differences only surface when everything is wired together. Which means they surface during deploys.

Fragmentation Is the Root Problem

Modern tooling didn't remove infrastructure complexity. It redistributed it.

Instead of managing servers, you manage integrations between services. Instead of a single failure domain, you have many.

A deploy can fail because of a CI issue, a registry timeout, a secret misconfiguration, a networking rule, or a scaling limit.

Each lives in a different system. Each requires different context.

Individually, these tools are well-designed. Collectively, they form a system that's hard to reason about under pressure.

This Model Breaks as You Scale

This only works while your system is small. But production systems don't stay small.

More services mean more pipelines. More configurations. More failure points.

Over time, the effort required to maintain your deployment system grows faster than the product itself.

That is the inflection point: where engineering time shifts away from building features and toward maintaining the machinery that ships them.

If you're already feeling that shift, it's not temporary. It's structural.

At some point, there's a question that becomes hard to ignore: Why are you still managing this yourself?

Not because you can't. But because it's no longer clear that you should.

The Shift Toward Platforms

This is where Platform as a Service changes the model. Not by adding more tools, but by taking ownership of the system those tools create.

A PaaS defines a path from code to production. That path is opinionated, constrained, and consistent.

Those constraints aren't limitations. They're what remove entire categories of failure.

Instead of assembling a deployment pipeline, you adopt one.

What You Stop Paying For

Moving to a PaaS is often framed as convenience. For production teams, it's closer to cost removal.

You stop spending time deciding how builds run, how services are exposed, how scaling is configured, and how logs are collected.

You stop debugging the integration points between those decisions. You trade flexibility for predictability.

And for most teams, predictability is the constraint that actually matters.

From Infrastructure Work Back to Product Work

The biggest change isn't in your architecture. It's in your allocation of engineering effort.

Time spent debugging deploys shifts back to building features. Time spent maintaining pipelines shifts to improving the product.

Deploys become routine again. Not because they're simpler in theory, but because the system around them is controlled.

Collapsing the Stack

The advantage of a PaaS isn't abstraction. It's consolidation.

Build, deploy, runtime, and observability are integrated into a single system.

There are fewer layers to coordinate. Fewer places to look when something fails. And fewer decisions to get wrong.

Platforms like Sevalla, Railway, and Render are pushing this further by tightening the loop between code and production, reducing both the number of systems involved and the surface area developers need to understand.

The goal is operational clarity.

The Trade-Off You Are Actually Making

The common objection is control. And it's valid. You give up the ability to customize every layer of your infrastructure.

But in practice, most teams aren't using that control to create differentiation. They're using it to keep a fragile system running, and it’s what keeps teams stuck maintaining systems they shouldn’t own.

Every custom configuration adds another failure point. Another dependency. Another thing to maintain under pressure.

The trade-off isn't control versus convenience. It's control versus reliability.

When This Becomes Urgent

You don't need a major outage to justify a change. The signals show up earlier.

Deploys feel unpredictable. Releases slow down. Engineers spend more time on pipelines than product logic. Onboarding takes longer than it should.

These aren't isolated issues. They are indicators that your current model isn't scaling with your system.

When Managing Infra Still Makes Sense

A PaaS may not right for every team.

If your app is still small, deployments are smooth, and your team isn't spending much time on infrastructure, you may not need a PaaS yet.

Some large companies also choose to build and manage their own platforms. For them, infrastructure is an important part of the business, so the extra work is worth it.

The important thing is making that choice on purpose.

Managing infrastructure is not always a bad thing. The real problem starts when app teams slowly take on platform work without enough people, clear ownership, or the right experience to handle it well.

What a “Simple Deploy” Actually Means

A simple deploy isn't one that feels easy when everything works. It's one that continues to work as your system grows.

It's predictable. Failures are rare. When they happen, they're easy to diagnose.

And most importantly, it doesn't require your engineers to think about infrastructure to ship code.

That outcome isn't achieved by adding more tools. It's achieved by reducing the system you have to manage.

Closing Thought

Your deploy didn't turn into a week of infrastructure work because you missed something. It turned into that because you're operating a model that expects you to.

You can continue investing in that model. Or you can adopt one where deploying is a solved problem.

For production teams, that's no longer a philosophical choice. It's an operational one.

Join my Applied AI newsletter to learn how to build and ship real AI systems. Practical projects, production-ready code, and direct Q&A. You can also connect with me on LinkedIn.

Every request emits logs. Every service exports metrics. Every dependency introduces another layer of signals.

In theory, this should make systems easier to understand. In practice, it does the opposite.

Dashboards become dense, alerts become noisy, and when something breaks, the same questions still come up: What's actually wrong? Who's affected? Where do you even start?

The problem isn't observability. It's interpretation.

Most teams aren't short on metrics. They're short on meaning.

And that gap exists because developers are often forced to reason about infrastructure when they should be focused on application behaviour.

Metrics exist to describe systems, but without the right level of abstraction, they become another layer of complexity.

This is where modern PaaS platforms change the equation. They don't remove metrics. Instead, they turn them into signals that developers can actually use.

This article breaks down five metrics that consistently matter in production systems. More importantly, it shows how a PaaS helps translate these metrics into something actionable, without requiring developers to act as infrastructure operators.

I’ll be using the Sevalla dashboard to explain these metrics, but other platforms like Railway and Render will have similar metrics.

What We'll Cover:

• What a PaaS Actually Does

• Latency Becomes a Clear Performance Signal

• Error Rate Becomes a Reliable Indicator of Failure

• Throughput Becomes Context Instead of a Problem

• Resource Utilisation Moves Out of the Critical Path

• Instance Health Becomes Invisible by Design

• From Metrics to Meaning

• Why This Matters for Developers

• The Real Advantage Is Clarity

What a PaaS Actually Does

A Platform as a Service (PaaS) is an abstraction layer over infrastructure that handles deployment, scaling, networking, and runtime management for you.

Instead of provisioning servers, configuring load balancers, and setting up autoscaling rules, you deploy your application and the platform takes care of how it runs in production.

Platforms like Sevalla, Railway, and Render operate on this model. The key shift is responsibility.

In a traditional setup, developers are responsible for both application behaviour and infrastructure behaviour. If latency spikes or errors increase, you have to determine whether the issue is in your code, your scaling rules, or the underlying system.

A PaaS moves most of that infrastructure responsibility into the platform.

You still get access to metrics, but many of the variables behind those metrics –instance lifecycle, scaling decisions, resource allocation – are handled automatically.

This changes how you interpret what you see.

Metrics stop being signals that require cross-layer investigation, and start becoming signals that map more directly to application behaviour.

Now let's see what can happen if your team switches to using a PaaS.

Latency Becomes a Clear Performance Signal

Latency is the most direct representation of user experience. It tells you how long your system takes to respond.

When latency increases, users feel it immediately. Pages slow down. APIs become unreliable. Even small delays impact engagement.

Most developers know to look at percentiles like p95 or p99 instead of averages. The slowest requests are what define perceived performance.

But in many environments, understanding latency isn't straightforward.

A spike could come from inefficient code. Or from cold starts. Or from scaling delays. Or from network routing issues. Developers are forced to investigate layers they didn't build.

This is where a PaaS changes the role of latency.

Instead of being a starting point for infrastructure debugging, latency becomes a clean signal of application performance. Scaling, routing, and resource allocation are handled by the platform. What remains is a clearer relationship between code and outcome.

When latency increases, developers can focus on what they actually control: queries, logic, and dependencies.

The metric stays the same. The meaning becomes clearer.

Error Rate Becomes a Reliable Indicator of Failure

Error rate answers a simple question. Is the system working or not?

It's usually measured as the percentage of requests that fail due to server-side issues. These are failures users can't recover from. A broken checkout flow or a failed API call directly impacts trust.

In theory, error rate should be one of the easiest metrics to act on. In practice, it rarely is.

Errors can come from application bugs, but also from timeouts, resource limits, failed deployments, or unstable instances. Developers end up correlating errors with infrastructure events just to understand what happened.

This slows everything down.

A PaaS reduces this ambiguity.

Failures caused by scaling, instance crashes, or transient infrastructure issues are handled at the platform level. Retries, isolation, and recovery mechanisms are built in.

What remains is a tighter link between error rate and application correctness.

When the error rate increases, it's far more likely to be something in the code or a dependency, not an invisible infrastructure issue.

This shifts the error rate from a noisy metric into a reliable signal.

Throughput Becomes Context Instead of a Problem

Throughput measures how many requests your system handles over time.

It provides context for everything else. Latency and error rate only make sense when you know how much traffic the system is handling.

A spike in latency during high traffic is expected. The same spike during low traffic is a warning sign.

But in many systems, throughput introduces operational complexity. Traffic changes require scaling decisions. Teams define autoscaling rules, tune thresholds, and try to predict demand. When things go wrong, they revisit those decisions.

Developers end up thinking about capacity instead of behaviour.

A PaaS shifts this responsibility. Scaling is automatic. Traffic spikes are absorbed by the platform. Developers don't need to decide how many instances should be running or when to scale.

Throughput becomes what it should be: context.

It helps explain what's happening, without forcing developers to manage how the system adapts.

Resource Utilisation Moves Out of the Critical Path

Resource utilization measures how much CPU, memory, and I/O your system consumes.

Traditionally, this has been central to operating systems. High CPU or memory usage signals potential issues. Teams monitor these metrics to avoid failures and plan scaling.

But for most developers, resource utilization isn't where value is created.

Yet in many environments, developers are still responsible for interpreting these signals. They tune memory limits, investigate CPU spikes, and try to optimise resource usage to keep systems stable.

This is operational work.

A PaaS changes the role of these metrics.

Resource management is handled by the platform. Allocation, scaling, and isolation happen automatically. Developers don't need to constantly watch CPU graphs or memory charts to keep the system running.

These metrics still exist, but they move into the background.

They become diagnostic tools rather than primary signals.

Developers can focus on performance at the application level, instead of managing how infrastructure behaves under load.

Instance Health Becomes Invisible by Design

Instance health tracks restarts, crashes, and lifecycle events.

In many systems, this is a critical metric. Frequent restarts indicate instability. Memory leaks, crashes, or resource exhaustion often show up here first.

Teams monitor instance health to catch issues early and prevent cascading failures.

But this also reveals something important: developers are aware of, and responsible for, the lifecycle of infrastructure. They track restarts, investigate crashes, and try to stabilise the system manually.

A PaaS removes this responsibility.

Unhealthy instances are restarted automatically. Load is redistributed. Capacity is maintained without manual intervention.

Instance health doesn't disappear, but it no longer requires constant attention. It becomes part of the platform’s internal behaviour, not something developers need to actively manage.

From Metrics to Meaning

These five metrics haven't changed.

Latency still reflects performance. Error rate still reflects correctness. Throughput still reflects demand. Resource utilization still reflects efficiency. Instance health still reflects stability.

What changes is how much work it takes to interpret them.

In lower-level environments, developers have to connect these signals themselves. A latency spike leads to checking throughput, then resource usage, then instance behaviour. Each step requires context, assumptions, and time.

This is where complexity accumulates.

A PaaS reduces that gap.

It handles scaling, recovery, and resource management so that metrics map more directly to application behaviour. The signals become easier to interpret because fewer variables are exposed.

Instead of asking multiple questions across layers, developers can move more directly from symptom to cause.

Why This Matters for Developers

Most developers don't want to manage infrastructure. They want to build features, ship improvements, and respond to user needs.

But as systems grow, operational responsibility expands. Monitoring becomes more complex. Debugging requires more context. A significant portion of time shifts from building to maintaining.

Metrics are part of this shift.

They're necessary, but they also reflect how much of the system you're responsible for understanding.

A PaaS doesn't eliminate metrics. It reduces the effort required to make sense of them.

It ensures that when something changes in production, the signals developers see are closer to the reality they care about: application behaviour. User experience. System correctness.

The Real Advantage Is Clarity

The goal is not to have fewer metrics.

It's to have metrics that mean something without requiring deep infrastructure reasoning.

These five metrics form a complete picture of system health. But their real value depends on how directly they map to what developers control.

The more layers you have to think about, the harder mapping becomes.

A good PaaS removes those layers. It turns metrics from raw data into usable signals.

And that shift from metrics to meaning is what allows developers to understand production systems without being buried under them.

Join my Applied AI newsletter to learn how to build and ship real AI systems. Practical projects, production-ready code, and direct Q&A. You can also connect with me on LinkedIn.

Let’s break them down clearly. We’ll go through VPS and PaaS in detail in terms of scaling, pricing, control, and so on. Each handles hosting very differently, and by the end of this guide, you’ll know exactly which solution fits your workflow better.

Table of Contents

• What is a VPS?

• What is a PaaS?

• Control and Customisation

• Setup and Deployment

• Scaling

• Maintenance and Updates

• Performance

• Security

• Pricing

• When to Use Each

• Summary

What is a VPS?

VPS stands for Virtual Private Server. Think of it as your own slice of a physical server.

Unlike shared hosting, where you compete for resources, a VPS gives you isolated computing power, dedicated RAM, CPU, and storage that’s all yours.

It acts like a mini datacenter. You gain root access, allowing you to install any OS (such as Ubuntu or CentOS), run custom applications, set up cron jobs, configure firewall rules, and essentially shape the environment as you see fit. It’s flexible, affordable, and powerful, and ideal for developers who want control without the complexity of managing bare-metal hardware.

What is a PaaS?

PaaS stands for Platform as a Service. It’s a cloud-based environment that lets you build, deploy, and scale applications without worrying about infrastructure.

Instead of provisioning servers or managing software stacks, you simply write your code, connect your Git repository, and hit deploy. The platform takes care of everything from building your app, routing traffic, provisioning SSL, scaling services, and monitoring health. It’s DevOps on autopilot.

PaaS solutions are built for speed and simplicity. They support modern languages and frameworks out of the box and offer smart features like auto-scaling, built-in CI/CD, and usage-based pricing.

Now let’s look at the main differences between the two options so you can decide which is best for your use case.

Control and Customisation

A VPS gives you full control. It’s your server, your rules.

You get root access, pick your OS, install whatever software you need, and tweak system settings to your liking. VPS solutions makes this easy by letting you deploy clean server images quickly like Ubuntu, Debian, Redhat or whatever suits you. Then it’s all in your hands.

PaaS, on the other hand, limits a bit of that flexibility in exchange for convenience. PaaS abstracts the system layer away completely and often comes with support which is handy if you need help.

You write code, push to a Git repo, and it takes care of the rest. It supports popular languages and frameworks, but if you need a very specific runtime or library, you might hit a wall.

If you like being in control, VPS wins here. If you’d rather avoid infrastructure altogether, PaaS is your solution.

Setup and Deployment

Getting a VPS up and running takes more effort. You’ll start by provisioning a server, then SSH in to install packages, configure firewalls, set up your web server, and deploy your code manually or via tools like Docker.

With PaaS, setup is nearly instant. You connect your GitHub or GitLab account, select your repo, and click deploy. It handles building, routing, SSL certificates, and launching the app, all within minutes. No SSH, no terminal commands, no surprises.

So if you want fast and repeatable deployments, PaaS is the smoother ride. If you’re okay spending more time upfront to craft your ideal setup, VPS gives you the flexibility.

Scaling

Scaling is one of the biggest advantages of PaaS. When your app traffic increases, it can spin up more containers or instances automatically.

You don’t have to predict resource needs ahead of time. Your app scales with demand and scales back down to save money when things quiet down.

With a VPS, scaling is more manual. You have to monitor usage and upgrade your server or configure load balancers yourself. Some developers enjoy this level of control, especially when optimising resource use. But it can be a headache during unexpected traffic spikes.

If your app is likely to grow or experience unpredictable load, PaaS gives you peace of mind. If your traffic is steady and predictable, VPS can handle it just fine, especially if you’re comfortable managing the growth yourself.

Maintenance and Updates

VPS means you’re in charge of everything under the hood. That includes system updates, security patches, disk usage, and log rotation. You also need to manage backups, monitoring, and anything else that keeps your app healthy and online.

PaaS removes that burden. The platform takes care of OS-level updates, security patches, and even restarts or auto-heals when something goes wrong. You get built-in monitoring and automatic backups, and logs are available right from the dashboard.

If maintenance isn’t your strong suit, or just not how you want to spend your valuable time, PaaS clearly comes out ahead.

Performance

With a VPS, you get guaranteed resources. They offers dedicated CPU cores and RAM that only your apps use. You can fine-tune performance at every level, from Nginx config files to memory usage. But I would recommend that you read the provider’s fine print and service terms as dedicated resources are not always fully dedicated.

PaaS solutions often run apps in shared or containerised environments. They manage performance for you and isolate workloads, but you might not have the same raw consistency as with a dedicated VPS, especially under heavy compute loads.

For apps that demand consistent high performance, like an online streaming service, a VPS is often the better choice. For most typical web apps, PaaS delivers more than enough speed and stability.

Security

In a VPS, security is your responsibility. That includes setting up firewalls, securing SSH access, managing user roles, and keeping the OS up to date. VPS gives you the tools, but it’s up to you to use them correctly.

PaaS handles most security concerns automatically, including DDoS protection. It provides HTTPS out of the box, isolates apps from each other, and keeps the platform patched and hardened. While you’re still responsible for securing your app code, you don’t have to worry about the infrastructure.

If security isn’t your strong point, or you want to reduce risk, PaaS adds a safety net. For experienced sysadmins, VPS offers the flexibility to build your own defenses.

Pricing

VPS pricing may appear more affordable at first glance. A VPS server with 4 GB RAM and 80 GB SSD might only set you back $10-15 per month. But that price is fixed, whether your app is serving ten users or ten thousand. And when you outgrow that plan, scaling means resizing the server or juggling additional machines.

PaaS platforms take a different approach. Instead of paying for fixed resources you may or may not use, you pay for what you actually consume. If your app gets minimal traffic, your costs stay low. But if usage spikes, PaaS scales your resources to match, without downtime or manual effort. You’re billed based on activity, not guesswork.

This makes PaaS a better long-term deal for most modern apps. You’re not locked into static hardware. You don’t have to overpay just to be “safe.” And as your app scales, your infrastructure scales with it automatically.

But keep in mind that since PaaS platforms scale automatically based on demand, a sudden spike in traffic can lead to unexpectedly high costs. To avoid surprise bills, make sure to set up pricing alerts and usage thresholds. Most PaaS providers offer these features to help you stay in control of your budget.

When to Use Each

Use a VPS if you need complete control, want to host multiple apps on one server, or have special requirements around software, performance, or system-level configuration.

Hetzner is a great choice when you want a solid server at a good price and are comfortable managing it yourself. It offers powerful virtual servers with full root access, making it a favorite among developers who want total control. If you’re comfortable managing your own infrastructure, Hetzner gives you the tools and flexibility to build exactly what you need.

Choose PaaS if you want to move fast, avoid infrastructure headaches, and focus purely on coding. PaaS lets you deploy and scale apps with minimal effort, which makes it ideal for teams that want to spend more time building and growing their business than managing.

Sevalla is a modern PaaS built for speed and simplicity. It handles everything from deployments to scaling, so you can focus entirely on writing code. With smart usage-based pricing and built-in automation, Sevalla is ideal for developers who want to move fast without managing servers or infrastructure.

Summary

There’s no one-size-fits-all answer when choosing between VPS and PaaS. It depends on your priorities, whether you care more about control or convenience, price or speed, flexibility or simplicity.

A VPS gives you a clean slate and full power under the hood. It’s ideal for experienced developers and sysadmins who want to build their environment from the ground up.

A PaaS offering gives you the tools to deploy fast, scale effortlessly, and skip the DevOps. It’s perfect if you’d rather write code than manage servers.

Hope you enjoyed this article. Connect with me on LinkedIn or visit my website.

Heroku is a well-known PaaS widely used by developers. And as a fun and useful project, you can easily make your own Heroku-like PaaS with Dokku.

What is Heroku?

Heroku is a platform as a service (PaaS) company founded in 2007. The platform runs on AWS, and its ephemeral storage system is called "Dyno".

Heroku is one of the most used PaaS by developers and for a good reason– it is easy to use, well documented, and supports several programming languages.

But what if you could deploy your own Heroku-like platform, including a CI/CD pipeline, database connections, HTTPS connections, and much more with one simple-to-use application?

Well, that is what Dokku provides and more. Let's take a look.

What is a PaaS?

Platform-as-a-Service (PaaS) is a software architecture style that provides an easy-to-use abstraction layer for deploying your application's code and managing it.

This allows you to focus on writing business logic rather than worrying about the platform itself.

PaaS providers usually provide their own database service as well as other related services, which can greatly simplify common development tasks.

The great advantage of PaaS is that the application developer doesn't need to perform any system administration work. Instead, you can just upload your code and configuration settings to a central server platform.

The service then takes care of deploying the code, scaling it as needed, backing up data, handling hosting and uptime concerns, and so on.

What is Dokku?

Dokku is a hosted Platform as a Service that enables developers to deploy their applications with ease.

From their website:

The smallest PaaS implementation you've ever seen

Dokku is based on Docker and uses Heroku's build-packs to compile and package your applications.

One of the best things about Dokku is that it is very lightweight and can be installed on a single server or VM.

It includes scalable hosting using Docker containers, continuous deployment with Git, and other popular DevOps tools.

Dokku also offers a variety of features, such as support for multiple languages, custom domains, automated deployments, and many more.

You can easily connect Postgres databases and even file storage to your applications.

You can check out more information at https://dokku.com/ or the documentation at: https://dokku.com/docs/getting-started/installation/.

You can also show some love for the open-source GitHub project here.

How to Install Dokku

In order to install Dokku you will need a Linux VPS and a domain name.

You can install and use Dokku without a domain name but it is much simpler using a domain. I recommend a cloud VPS because it makes it easier to access and configure.

When connecting a domain, either a single domain or a wildcard can be associated with the server's IP.

I will be using a VPS hosted on Hetzner with Ubuntu 20.04 installed.

We first start by making sure that our system is up to date with these commands:

# Update the linux installation
$ sudo apt update
$ sudo apt upgrade -y

Then we can download and run the installation script for Dokku:

# Install Dokku with the install script
$ wget https://raw.githubusercontent.com/dokku/dokku/v0.26.8/bootstrap.sh;
$ sudo DOKKU_TAG=v0.26.8 bash bootstrap.sh

--> Ensuring we have the proper dependencies
--> Note: Installing dokku for the first time will result in removal of
    files in the nginx 'sites-enabled' directory. Please manually
    restore any files that may be removed after the installation and
    web setup is complete.

    Installation will continue in 10 seconds.

    [...........]

    --> Running post-install dependency installation

 ! Setup a user's ssh key for deployment by passing in the public ssh key as shown:

     echo 'CONTENTS_OF_ID_RSA_PUB_FILE' | dokku ssh-keys:add admin

The installation script will install Docker and all necessary dependencies and also Dokku itself, as seen in the code above.

After the installation is complete we need to assign the SSH keys to access and also configure our domain name.

In case you have set up access to your VPS with SSH (which you should) then you already have the necessary keys – you just need to add them to Dokku:

# Assign SSH key to Dokku
$ cat ~/.ssh/authorized_keys | dokku ssh-keys:add admin

SHA256:6O1TLVOUkWV+zmTWXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

In case you don't already have an SSH key in the server, then you need to generate a key pair:

# Generate SSH key
$ ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa
Your public key has been saved in /root/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:7T6BbRCVWjGtcSUXXXXXXXXXXXXXXXXXXXXXXXXXXXXX root@freeDokku
The key's randomart image is:
+---[RSA 3072]----+
[.................]
|     . oS*.o . . |
[.................]
+----[SHA256]-----+

Then you can add it to Dokku:

# Add SSH key to Dokku
$ dokku ssh-keys:add admin /root/.ssh/id_rsa.pub

SHA256:7T6BbRCVWjGtcSUXXXXXXXXXXXXXXXXXXXXXXXX

Next, and the final step, is to assign the domain for your Dokku installation. We do that with the command:

# Set installation global domain
$ dokku domains:set-global domain.com

-----> Set domain.com

Make sure you replace 'domain.com' with your own domain, and that your domain name DNS points to the server's IP address.

And that is all you need to do to install and set up Dokku. It is really that simple.

You can now start adding your applications.

Let's see an example of that by adding a standard Django application in the next section.

How to Create Your Application in Dokku

To create and deploy our first application, there is some preparation work we need to do on Dokku.

To deploy an application on Dokku, follow these steps:

• Create the application on Dokku, which means giving it a name.
• Create the associate database (or other plugins, if needed). This will create and provision a database for use with an automatic DATABASE_URL added to the application for ease of deployment.
• Push the necessary code to Dokku's application internal GitHub endpoint. This can include also the necessary release steps (like running Django migrations, for example).

After the code is pushed, Dokku will generate any necessary Docker container and will run our application with any associated databases (or other plugins).

Now that we've covered the necessary steps, let's go through them in practice.

Let's start by creating our application. For this tutorial, I will create a very simple Django website that contains all the necessary logic for us to test Dokku.

We create an application on Dokku with this command (in the server where we installed Dokku):

# Creating our application on Dokku
$ dokku apps:create djangotutorial

-----> Creating djangotutorial...

By default, datastores (or databases) are not created when an application is created.

The datastores are handled by a series of plugins. You can check here for all available plugins.

For our application, we will create a Postgres datastore. Since by default no plugins are installed, we first need to install the Postgres plugin:

# install the postgres plugin
# plugin installation requires root, hence the user change
sudo dokku plugin:install https://github.com/dokku/dokku-postgres.git

Then we can create our Postgres datastore:

# Create a Postgres datastore
$ dokku postgres:create djangotutorial_datastore

       Waiting for container to be ready
       Creating container database
       Securing connection to database
=====> Postgres container created: djangotutorial_datastore
=====> djangotutorial_datastore postgres service information
       Config dir:          /var/lib/dokku/services/postgres/djangotutorial_datastore/data
       Config options:
       Data dir:            /var/lib/dokku/services/postgres/djangotutorial_datastore/data
       Dsn:                 postgres://postgres:ea706cc108c805d5124d134d934024c5@dokku-postgres-djangotutorial-datastore:5432/djangotutorial_datastore
       Exposed ports:       -
       Id:                  782a04fe6bbd25958752c17c304358fd5ec1f3c54d6d53175b6481b3b957d94b
       Internal ip:         172.17.0.5
       Links:               -
       Service root:        /var/lib/dokku/services/postgres/djangotutorial_datastore
       Status:              running
       Version:             postgres:14.1

We can check that our Docker container for the datastore is already up and running with:

# Check running containers
$ docker ps

CONTAINER ID   IMAGE                      COMMAND                  CREATED              STATUS              PORTS      NAMES
782a04fe6bbd   postgres:14.1              "docker-entrypoint.s…"   About a minute ago   Up About a minute   5432/tcp   dokku.postgres.djangotutorial_datastore

Now that we have the datastore up and running, we need to associate it with our application:

# Associate datastore with the application
$ dokku postgres:link djangotutorial_datastore djangotutorial

-----> Setting config vars
       DATABASE_URL:  postgres://postgres:ea706cc108c805d5124d134d934024c5@dokku-postgres-djangotutorial-datastore:5432/djangotutorial_datastore
-----> Restarting app djangotutorial
 !     App image (dokku/djangotutorial:latest) not found

You can see that a DATABASE_URL is automatically created and associated with the application.

The example above mentions that our application image is not found because we haven't pushed any code to it yet.

We can check our application's environment variables to confirm that our DATABASE_URL is present:

# Checking an application environment variables
$ dokku config:show djangotutorial

=====> djangotutorial env vars
DATABASE_URL:  postgres://postgres:ea706cc108c805d5124d134d934024c5@dokku-postgres-djangotutorial-datastore:5432/djangotutorial_datastore

We now have all the necessary configurations done on the Dokku side to support the deployment of our application.

Next, we will create the code for our application and deploy that to Dokku for an automated CI/CD pipeline.

How to Create Our Application Code on PyCharm

Before we can deploy an application, we need to have its source code to push to Dokku.

For this tutorial, we are going to create a very simple Django application that shows also the use of the Postgres database.

We will be using PyCharm as our IDE to create and manage our project.

We create a new project in PyCharm – let's call it 'DjangoTutorial':

Creating a new project on PyCharm - Screenshot by author

I personally prefer to create new projects with a virtual environment already in place, which makes life much easier.

If you created the project with a default main.py file (like I did because I keep forgetting to remove the checkmark), you can safely delete it now. We are not going to use it.

The first step is, of course, to install Django so we can build our application. We do that install using pip:

$ pip install django

Collecting django
  Downloading Django-4.0.2-py3-none-any.whl (8.0 MB)
     |████████████████████████████████| 8.0 MB 6.4 MB/s
Collecting sqlparse>=0.2.2
  Using cached sqlparse-0.4.2-py3-none-any.whl (42 kB)
Collecting tzdata
  Using cached tzdata-2021.5-py2.py3-none-any.whl (339 kB)
Collecting asgiref<4,>=3.4.1
  Downloading asgiref-3.5.0-py3-none-any.whl (22 kB)
Installing collected packages: tzdata, sqlparse, asgiref, django
Successfully installed asgiref-3.5.0 django-4.0.2 sqlparse-0.4.2 tzdata-2021.5

Then we create our Django project with:

$ django-admin startproject DjangoTutorial .

Notice the '.' at the end of the command. I like to use that so that it creates the project in the current directory instead of creating an extra sub-directory.

You should now have a project structure like this in PyCharm:

PyCharm folder structure for our Django application - screenshot by the author

We can run our project with the standard Django run:

$ python manage.py runserver   

Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
February 02, 2022 - 16:49:27
Django version 4.0.2, using settings 'DjangoTutorial.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.

We have not yet applied our migrations, so we will do that next after we discuss the database configuration for both local and Dokku access.

Navigating to the link http://127.0.0.1:8000/, we can now access our standard Django welcome page:

Django welcome page - screenshot by the author

We have our Django installation up and running so now we can start building the rest of the project.

Like most projects, we will need to store data in a database (or database using the Dokku naming).

We also want to be able to debug and run our application locally on the development machine (using a local database, in this SQLite) and run it on the cloud with Dokku using the Postgres database.

This means we need to change some configuration in our settings.py to be able to support both use cases without us needing to change any flags or configs every time.

We start by installing the package dj-database-url with:

# Install packages for the database url
$ pip install dj-database-url
$ pip install psycopg2


# We also install this package to be able to use environment variables
$ pip install python-decouple

This package enables us to have a Django database connection dictionary, populated with all the data by simply specifying a database URL.

With the package install, let's update the configuration on the settings.py:

# We need to add this import at the beginning to use environment variables
import dj_database_url
from decouple import config
from django.conf.global_settings import DATABASES

.....

# Let's also updated the allowed host so we can use it later on
ALLOWED_HOSTS = config('ALLOWED_HOSTS').split(',')

.....

# We replace the default database configuration from Django with this one
# Database
# https://docs.djangoproject.com/en/4.0/ref/settings/#databases

# DATABASE URL
DATABASES['default'] = dj_database_url.parse(config('DATABASE_URL'),conn_max_age=600)

We will also need to create '.env' file in the root dir of our project:

#HOST SETTINGS
ALLOWED_HOSTS = 127.0.0.1

#DATABASE SETTINGS
DATABASE_URL='sqlite:///db.sqlite3'

As you can see, with this change we can use the database URL from the local '.env' file on the local development machine, and then on Dokku it will automatically use the already defined DATABASE_URL that was created when we linked the datastore to the application on Dokku.

We can now create our first (and only) web page of this tutorial), a simple counter that stores and read the value from the database.

Let's create a separate application to contain our logic:

$ python manage.py startapp counter

We now should have a new folder called 'counter' in our project. Let's add a new model by opening the 'models.py' file:

from django.db import models


class Counter(models.Model):
    count = models.IntegerField(default=0)

    def __str__(self):
        return self.count

We can now add a new URL to load our counter page. We do that by adding a new file called 'urls.py' to our 'counter' folder:

from django.urls import path
from . import views

urlpatterns = [
    path('counter/', views.counter, name='counter'),
]

We now have both the model and the URL to load our test page. All we need now is the view and HTML template to render the page.

Let's create the view by editing the 'views.py' file:

from django.shortcuts import render
from .models import Counter


def counter(request):
    counter_value = Counter.objects.last()

    if counter_value is None:
        counter_value = Counter(count=0)
        counter_value.save()

    if request.method == 'POST':
        counter_value.count += 1
        counter_value.save()

    return render(request, 'counter.html', {'counter': counter_value.count})

Now we can create our HTML template to show the counter value on the page. We create a new file called 'counter.html' inside a new 'templates' folder:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Counter</title>
</head>
<body>
  <form method="post">
      {%csrf_token%}
    <h4>Counter value is: {{ counter }}</h4>
    <input type="submit" name="submit" value="Increase Counter">
  </form>
</body>
</html>

The last step is to add our newly created application to the 'settings.py' file in order for Django to recognize it:

.....

INSTALLED_APPS = [
    'counter',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

.....

And the URL to our main URLs file:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('', include('counter.urls')),
    path('admin/', admin.site.urls),
]

With all the necessary code and HTML in place, we can now create and run our migrations to create our new model in the database. We first do that on the local server by running:

# Create and run migrations
$ python manage.py makemigrations
$ python manage.py migrate

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, counter, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying counter.0001_initial... OK
  Applying sessions.0001_initial... OK

As you can see, we not only applied the migrations for our new application but we also run the initial migrations for the other Django applications since this was the first time we ran the migrations.

We can again run our server locally and we should be able to access the URL http://127.0.0.1:8000/counter/ and increment the counter:

Running our counter application - GIF by the author

As you can see, reloading the page keeps our counter value, meaning that the value is been stored in the database with our model.

How to Deploy Our Application to Dokku

We now have a very simple application running with database integration to store our counter value.

We are ready to deploy it to the cloud so we can test it there and make sure our database is also working in the cloud.

Before we do the Git push to deploy the code to Dokku, we need to do some preparation:

• Install our web server (gunicorn)
• Create our requirements file (for our packages)
• Create our Procfile (for our deployment commands)

Let's start with installing our web server to use in the cloud:

# Install our web server
$ pip install gunicorn

With our packages in place we can now create our requirements file with:

# Create requirements file
$ pip freeze > requirements.txt

Now we need to create the 'Procfile'. This file is used by Dokku to determine which commands to run on deployment and after deployment.

So let's create a new file called 'Procfile' in the root directory with the contents:

web: gunicorn DjangoTutorial.wsgi
release: python manage.py migrate

We have created two commands for Dokku to run:

• release – this command is executed on the deployment of our application in Dokku. We use it to migrate our database.
• web – this command allows Dokku to know which webserver to run to allow access to the application.

Finally, to make sure that we can collect any static files when our code is deployed to Dokku, we need to create a new directory called 'static' on the root directory. Inside we create an empty file called '.gitkeep' (this will allow us to add the directory to the Git repository later).

We also need to add this path for the static files to our 'settings.py' file:

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/4.0/howto/static-files/

STATIC_URL = 'static/'
STATIC_ROOT = BASE_DIR / "static"

Now all the files and logic are in place and we can deploy to Dokku with a standard Git push. Let's check our current file structure:

PyCharm folder structure - screenshot by the author

To be able to push our code to Dokku, we need to add our project to a Git repository.

Since we don't want to push all the files from our folder structure to the Dokku git repository, we create a '.gitignore' to exclude certain files and directories. I use the contents of this excellent Gist to populate the file:

We can now initialize and commit our code to a Git repository locally:

# Initialize repository
$ git init -b main

# Add and commit our files
$ git add . && git commit -m "initial commit"

[main (root-commit) e77a16a] initial commit
 20 files changed, 438 insertions(+)       
 create mode 100644 .gitignore
 create mode 100644 DjangoTutorial/__init__.py
 create mode 100644 counter/tests.py
 create mode 100644 counter/urls.py
 create mode 100644 counter/views.py
 create mode 100644 db.sqlite3
 create mode 100644 manage.py
 create mode 100644 requirements.txt

With our repository committed, we can now push it to a remote repository, that is the Dokku Git repository for our application:

# Adding our remote repository (replace domain.com with your domain name)
$ git remote add dokku dokku@domain.com:djangotutorial

# Time to push our code to the remote repository
$ git push dokku main

Enumerating objects: 34, done.
Counting objects: 100% (34/34), done.
Delta compression using up to 8 threads
Compressing objects: 100% (31/31), done.
Writing objects: 100% (34/34), 11.41 KiB | 402.00 KiB/s, done.
Total 34 (delta 7), reused 0 (delta 0)
-----> Set main to DOKKU_DEPLOY_BRANCH.
-----> Cleaning up...
-----> Building djangotutorial from herokuish
-----> Adding BUILD_ENV to build environment...
       BUILD_ENV added successfully
-----> Python app detected
-----> No Python version was specified. Using the buildpack default: python-3.9.9
       To use a different version, see: https://devcenter.heroku.com/articles/python-runtimes
-----> No change in requirements detected, installing from cache
-----> Installing python-3.9.9
-----> Installing pip 21.3.1, setuptools 57.5.0 and wheel 0.37.0
-----> Installing SQLite3
-----> Installing requirements with pip
       Collecting asgiref==3.5.0
       Downloading asgiref-3.5.0-py3-none-any.whl (22 kB)
       Collecting dj-database-url==0.5.0
       Downloading dj_database_url-0.5.0-py2.py3-none-any.whl (5.5 kB)
       Collecting Django==4.0.2
       Downloading Django-4.0.2-py3-none-any.whl (8.0 MB)
       Collecting gunicorn==20.1.0
       Downloading gunicorn-20.1.0-py3-none-any.whl (79 kB)
       Collecting psycopg2==2.9.3
       Downloading psycopg2-2.9.3.tar.gz (380 kB)
       Preparing metadata (setup.py): started
       Preparing metadata (setup.py): finished with status 'done'
       Collecting python-decouple==3.5
       Downloading python_decouple-3.5-py3-none-any.whl (9.6 kB)
       Collecting sqlparse==0.4.2
       Downloading sqlparse-0.4.2-py3-none-any.whl (42 kB)
       Collecting tzdata==2021.5
       Downloading tzdata-2021.5-py2.py3-none-any.whl (339 kB)
       Building wheels for collected packages: psycopg2
       Building wheel for psycopg2 (setup.py): started
       Building wheel for psycopg2 (setup.py): finished with status 'done'
       Created wheel for psycopg2: filename=psycopg2-2.9.3-cp39-cp39-linux_x86_64.whl size=579484 sha256=9d6a2810a5d766738526d6f411e5e9ce514cce882b6c80a47a13c02dc7529e02
       Stored in directory: /tmp/pip-ephem-wheel-cache-8k0chg5g/wheels/b3/a1/6e/5a0e26314b15eb96a36263b80529ce0d64382540ac7b9544a9
       Successfully built psycopg2
       Installing collected packages: sqlparse, asgiref, tzdata, python-decouple, psycopg2, gunicorn, Django, dj-database-url
       Successfully installed Django-4.0.2 asgiref-3.5.0 dj-database-url-0.5.0 gunicorn-20.1.0 psycopg2-2.9.3 python-decouple-3.5 sqlparse-0.4.2 tzdata-2021.5
-----> $ python manage.py collectstatic --noinput
       128 static files copied to '/tmp/build/static'.

-----> Discovering process types
       Procfile declares types -> release, web
-----> Releasing djangotutorial...
-----> Checking for predeploy task
       No predeploy task found, skipping
-----> Checking for release task
-----> Executing release task from Procfile: python manage.py migrate
=====> Start of djangotutorial release task (a602cab30) output
       Operations to perform:
         Apply all migrations: admin, auth, contenttypes, counter, sessions
       Running migrations:
         Applying contenttypes.0001_initial... OK
         Applying auth.0001_initial... OK
         Applying admin.0001_initial... OK
         Applying admin.0002_logentry_remove_auto_add... OK
         Applying admin.0003_logentry_add_action_flag_choices... OK
         Applying contenttypes.0002_remove_content_type_name... OK
         Applying auth.0002_alter_permission_name_max_length... OK
         Applying auth.0003_alter_user_email_max_length... OK
         Applying auth.0004_alter_user_username_opts... OK
         Applying auth.0005_alter_user_last_login_null... OK
         Applying auth.0006_require_contenttypes_0002... OK
         Applying auth.0007_alter_validators_add_error_messages... OK
         Applying auth.0008_alter_user_username_max_length... OK
         Applying auth.0009_alter_user_last_name_max_length... OK
         Applying auth.0010_alter_group_name_max_length... OK
         Applying auth.0011_update_proxy_permissions... OK
         Applying auth.0012_alter_user_first_name_max_length... OK
         Applying counter.0001_initial... OK
         Applying sessions.0001_initial... OK
=====> End of djangotutorial release task (a602cab30) output
-----> App Procfile file found
=====> Processing deployment checks
       No CHECKS file found. Simple container checks will be performed.
       For more efficient zero downtime deployments, create a CHECKS file. See https://dokku.com/docs/deployment/zero-downtime-deploys/ for examples
-----> Deploying djangotutorial via the docker-local scheduler...
-----> Deploying web (count=1)
       Attempting pre-flight checks (web.1)
       Waiting for 10 seconds (web.1)
       Default container check successful (web.1)
-----> Deploying release (count=0)
-----> Running post-deploy
-----> Creating new app virtual host file...
-----> Configuring djangotutorial.domain.com...(using built-in template)
-----> Creating http nginx.conf
       Reloading nginx
-----> Renaming containers
       Renaming container djangotutorial.web.1.upcoming-7101 (f8d229ebd8bc) to djangotutorial.web.1
-----> Checking for postdeploy task
       No postdeploy task found, skipping
-----> Updated schedule file
=====> Application deployed:
       http://djangotutorial.domain.com

To domain.com:djangotutorial
 * [new branch]      main -> main

We have just deployed our application to Dokku.

What just happened? Well, Dokku did a lot of work for us:

• Installed Python
• Installed the requirements
• Collected the static files
• Performed the migrations
• And finally started a gunicorn server to deploy our application

If you had a permission error, then your private key should be registered within your local development environment. If you get a permission denied error when pushing, you can register your private key as follows: ssh-add -k ~/<your private key>.

You may also see an error regarding the ALLOWED_HOSTS when accessing the application. In that case, all you need to do is to run the following command on the Dokku server to set the environment variable to the correct value:

# Set ALLOWED_HOSTS environment variable (make sure to use your domain name)
$ dokku config:set djangotutorial ALLOWED_HOSTS=djangotutorial.domain.com

We can now access and test our application at the above URL:

Running our counter application on Dokku - GIF by the author

Congratulations, you just deployed your application on Dokku.

How to Add SSL with Let's Encrypt

One final configuration that we can do is to add SSL security to our application by installing a Let's Encrypt SSL certificate.

We can do this very easily on Dokku with the Let's Encrypt plugin:

# Install the Let's Encrypt plugin
sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git

# Configure the plugin (make sure to replace to your email)
dokku config:set --global DOKKU_LETSENCRYPT_EMAIL=email@domain.com

# set a custom domain that you own for your application
dokku domains:set djangotutorial djangotutorial.your.domain.com

# Enable Let's Encrypt
dokku letsencrypt:enable djangotutorial

# Enable Let's Encrypt auto-renewal
dokku letsencrypt:cron-job --add

Now we have a more secure application. After all, our counter is very important.

Conclusion

Using a PaaS makes a developer's life easier when building web applications.

You can use hosted PaaS like Heroku and there are many others, so the choice is there.

But there are some main drawbacks:

• Price – hosted solutions might have limits in terms of database storage or file storage, among others
• You don't control the hosting where the PaaS is deployed. Recent examples of AWS shows that not even the biggest hosting is free of problems.

You can work around these issues by self-hosting your PaaS.

This allows for more control in terms of pricing. You can use hosting provider like Digital Ocean, Hetzner, and others who have quite cheap VPSs that work perfectly with Dokku.

There are no database limits. The only limits you might have are memory and disk space, but you can always upgrade your VPS for a smaller price than getting a new database at Heroku.

Dokku is easy to install and like we saw. Creating and deploying an application is a 3 step process:

• Create an application on Dokku
• Create a datastore on Dokku (if needed, like Postgres) and link to the application
• Deploy your code to Dokku with Git

Additionally, you might need to configure some environment variables and SSL certificates, but that is all.

Dokku is really the smallest PaaS implementation.

Full source code for the Django application is available at:

Follow me on Twitter: https://twitter.com/DevAsService

Check out my website at: https://developer-service.io/

Or check out my blog at: https://blog.developer-service.io/