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/