Developer guide to building apps without carrying the infrastructure burden

Most application developers spend a significant amount of time on tasks that have nothing to do with building features. Sprint 0 disappears into Jenkins files and Terraform configs. New environments require tickets to multiple teams and a one-to-two week wait. Runtime upgrades stretch into months-long projects.

This is the infrastructure tax, and it compounds. Every hour spent debugging IAM permissions or waiting for environment provisioning is an hour not spent on the product. The tools designed for infrastructure specialists (Terraform, Kubernetes, raw cloud configs) have become default expectations for application developers who never signed up for that work.

There's a cleaner split between what developers should own and what should be automated. Getting that split right changes how teams plan, build, and ship.

What "not carrying the infrastructure burden" actually means

Let us be clear about what we are not suggesting: abandoning all infrastructure knowledge or pretending deployment does not matter. The goal is to separate what you need from how it gets provisioned.

Infrastructure should be a dependency of your application, just like any other dependency in your codebase. You declare what you need (a PostgreSQL database, a Redis cache, a Node.js runtime), and the platform handles the rest. Beyond the contract between your application code and a dependency, you should not need to worry about how that dependency runs.

In practice, this means no more writing Terraform modules to provision managed databases. No more debugging Kubernetes YAML when your pod will not schedule. No more context-switching between your IDE and cloud provider consoles to figure out why IAM permissions are blocking your deployment.

You write code. You push to Git. Your application runs.

Infrastructure abstraction: what developers should keep control of

Not everything should be abstracted away. Some infrastructure decisions directly affect how your application behaves, and those belong with the development team.

• Application architecture decisions remain yours. Can your application run properly in a multi-node setup? Does it handle horizontal scaling gracefully? These questions require understanding your code, not your cloud provider.
• Service selection stays with you. You know whether your workload needs PostgreSQL or MySQL, whether Redis makes sense for your caching strategy, and whether Elasticsearch fits your search requirements. The platform should make these services available instantly, but the choice is yours.
• Performance requirements are your domain. How much CPU and memory does your application need? What response times do your users expect? You understand these constraints better than any infrastructure team.
• Business logic and data flow obviously stay with you. How your application processes requests, stores data, and handles errors is core development work.

What should be abstracted away

Everything else. Specifically, anything that requires specialist infrastructure knowledge but does not change how your application code works.

• Environment provisioning should not consume your Sprint 0. When a platform handles this automatically, you go from committing code to having a running environment in minutes instead of days or weeks. Every Git branch can generate a complete environment with the same configuration, services, routing, and optional production data.
• Networking and routing configuration should be invisible. TLS certificates, load balancing, DNS management, and service discovery can all be handled by the platform. You should not need to understand VPCs or security groups to deploy a web application.
• Runtime and service updates should not be months-long projects. As a developer, you should not care about sub-point versions of your runtime or service. You should not have to deal with updating them because that is not your focus. Your focus should be on building new value or maintaining your application.
• Infrastructure security is where guardrails should replace decision-making entirely. Read-only production file systems, automated TLS certificates, strict environment isolation: these should be built in, not configured.

How reduced infrastructure overhead change development speed

When you remove infrastructure from your critical path, development speeds up.

• Faster feedback loops become the norm. When creating a test environment takes seconds instead of filing tickets, you test more frequently. You catch problems earlier. You ship with more confidence.
• Feature branches become real environments. Every branch you push can become a fully independent environment, complete with your application code, a copy of your database, and all supporting services. Its automatically generated URL can be sent to stakeholders or CI systems. It really is "what would my site look like if I merged this to production?" every time.
• Sprint planning changes. Without Sprint 0 infrastructure work, you start building features on day one. Without environment provisioning delays, you stop padding estimates with "infrastructure time." You plan based on development complexity, not operational overhead.
• On-call becomes less stressful. When infrastructure is predictable and rollbacks are reliable, sleep improves. Seriously.

Common fears about giving up low-level control

Teams often hesitate to adopt standardized environments because they worry about losing flexibility. Let us address the most common concerns.

• "What if I need a custom configuration?" Standardized does not mean rigid. A well-designed platform exposes configuration where it matters (resource allocation, service selection, environment variables, etc.) while hiding complexity where it does not (networking, IAM, scaling mechanics).
• "What about vendor lock-in?" Your application code does not change. Your database schemas stay the same. Your APIs remain identical. The portability that matters, your actual application, stays portable.
• "How do I debug production issues?" Better than you do now, likely. When every environment is identical (same configuration, same services, same data structure), debugging "works on my machine" problems disappear. Full-production clones in minutes let you test in real conditions without touching live systems.
• "What about compliance and security requirements?" Built-in compliance (SOC 2, ISO 27001, PCI-DSS) often exceeds what teams achieve with DIY setups. When security is baked into the platform, you inherit it automatically.

What enables confidence when infrastructure is automated

Confidence comes from predictability. When you understand exactly what will happen each time you deploy, fear decreases.

• Git becomes the single source of truth. Your infrastructure configuration lives alongside your code in a simple YAML file. Infrastructure changes go through pull requests with the same review process as code changes. Every deployment is deterministic based on Git commits. Rolling back means reverting commits.
• Configuration stability over time. One challenge with Terraform is version upgrades and syntax changes between versions. Upgrading Terraform is often significant work. With standardized platforms, a configuration file from years ago still works today.
• Environment parity is guaranteed. The same configuration deploys to development, staging, and production. Environment-specific differences are handled through variables, not different configurations. Drift between environments simply does not happen.

Getting started

The path forward does not require rewriting your application or abandoning everything you know. Start with a non-critical project. Create a simple configuration file. Push to Git. Watch your application deploy.

When you see how fast that feedback loop can be, when you experience creating a complete environment from a branch in seconds, the infrastructure burden starts feeling like a problem that belongs in the past.

You became a developer to build things. It is time to get back to that.

Learn more

• What is Upsun? 
  Understand the core concepts behind Git-driven infrastructure and how Upsun abstracts away operational complexity.
• Git-Driven Infrastructure: Why Configuration as Code Beats Click-and-Deploy.
  A deeper look at why YAML-driven deployments outperform manual provisioning for maintainable, scalable applications.
• Set up your local development environment.
  Connect your local workflow to Upsun using DDEV or SSH tunnels to iterate faster without pushing every change.
• Command line interface (CLI)
  Manage projects, environments, and deployments directly from your terminal with the Upsun CLI.
• Manage Upsun environments.
  Learn how to create, branch, sync, and merge environments tied to your Git workflow.