What is cloud development? A technical guide for engineering teams

Cloud development is how most engineering teams build and ship software today. Instead of relying on local machines and on-premises servers, teams use cloud infrastructure to write, test, and deploy applications at every stage of the development lifecycle.

This guide covers what cloud development means in practice, how it differs from traditional development, and how modern engineering teams structure their cloud workflows.

Cloud development is the practice of building, testing, and deploying software applications using cloud-based infrastructure and services. Rather than running development tooling, build pipelines, and production workloads on local machines or privately managed servers, teams use compute, storage, and networking resources provided by cloud platforms.

Cloud development covers the full software delivery lifecycle: from writing code in a remote development environment, to running automated tests in cloud-hosted CI/CD pipelines, to deploying containerised applications on orchestrated infrastructure. It is not a single tool or product but a set of practices and infrastructure patterns that together move software delivery off local machines and onto cloud platforms.

Traditional development relies on each engineer configuring their own local machine. That works for small, simple projects, but breaks down as teams and codebases grow.

Cloud development moves the infrastructure into shared, reproducible environments managed centrally by the platform or platform engineering team.

The practical difference shows up during onboarding and debugging. A new engineer joining a team using cloud development gets a fully configured environment in minutes. On a traditional setup, they spend half their first week resolving dependency conflicts that only affect their machine.

A cloud development environment (CDE) is a remote, pre-configured workspace that runs in the cloud rather than on a developer's local machine. Engineers connect to it through a browser or a local IDE like VS Code or JetBrains, while all compute, storage, and tooling run remotely.

CDEs solve the consistency problem at the root. Because the environment is defined as code (using tools like Dev Containers or Dockerfile-based templates), every engineer on the team gets identical tooling, package versions, and access to services. There is no "works on my machine" because there is no "my machine" in the traditional sense.

Key characteristics of a CDE:

• Reproducible: Defined declaratively, so the environment is identical every time it is provisioned.
• Ephemeral: Environments can be created per branch or per pull request and torn down after use.
• Centralised: Managed by the platform engineering team, not individual developers.
• Resource-efficient: Compute is released when the environment is not in use.

Common CDE platforms include GitHub Codespaces, Gitpod, and Coder. These handle the development side of the workflow. Teams also need a deployment platform like Northflank to run the resulting applications, covering services, databases, workers, and preview environments per pull request.

Cloud-native application development is a specific approach to building software that is designed from the ground up to run on cloud infrastructure. It is a subset of cloud development, not a synonym for it.

Cloud-native applications are built around four core principles:

• Containers: Each service runs in an isolated container, typically managed by Kubernetes.
• Microservices: The application is decomposed into small, independently deployable services rather than a monolith.
• Declarative APIs: Infrastructure and configuration are defined as code and applied through APIs, not manual processes.
• CI/CD: Every change moves through an automated pipeline from commit to deployment.

Cloud-native is distinct from simply running an existing application on a cloud server. Lifting a monolith onto a virtual machine is cloud hosting, not cloud-native development. Cloud-native means rebuilding that application as containerised microservices with CI/CD and declarative infrastructure.

A cloud development workflow spans several layers of infrastructure and tooling. Understanding how each layer fits together helps teams make better decisions about what to build versus what to buy.

• Source control and CI/CD: Every change starts in a Git repository. CI/CD pipelines run tests, build container images, and trigger deployments on every push or pull request. GitHub Actions, GitLab CI, and similar tools sit in this layer.
• Containerisation: Applications are packaged as container images using Docker. Kubernetes orchestrates those containers across cloud infrastructure, handling scheduling, networking, health checks, and scaling.
• Cloud infrastructure: Compute, storage, and networking are provisioned on cloud providers like AWS, GCP, or Azure, or on managed platforms that abstract the underlying infrastructure entirely.
• Managed databases and services: Rather than managing database servers manually, teams use managed database services, either from a cloud provider or from a platform that provisions and operates them on your behalf.
• Preview environments: Each pull request or feature branch can have a dedicated preview environment (a fully running instance of the application on live infrastructure). This allows changes to be reviewed in context before they reach staging or production. Northflank provides preview environments that spin up per branch and tear down after merge.
• Observability and logging: Centralised log aggregation, metrics, and tracing give teams visibility into what is running in the cloud. This is harder to replicate on local machines and is one of the practical advantages of a cloud-first workflow.

Teams running cloud development workflows choose between three main deployment models depending on their compliance requirements, cost constraints, and existing infrastructure.

Hybrid and multi-cloud models are increasingly common. Teams use them to keep sensitive data on private infrastructure while running stateless services on public cloud, or to deploy workloads in the region closest to their users. For a detailed breakdown, see What is hybrid cloud? and Northflank's guide to multi-cloud container orchestration.

Cloud development involves tooling across several categories. Most engineering teams combine tools from multiple categories rather than relying on a single platform.

• IDEs and CDEs: VS Code with Remote SSH or Dev Containers extensions, GitHub Codespaces, Gitpod, and Coder all support remote development. JetBrains also supports remote backend connections via JetBrains Gateway.
• Infrastructure provisioning: Terraform and Pulumi define cloud resources as code. They handle VPCs, storage buckets, DNS records, and managed services in a reproducible, version-controlled way.
• Container orchestration: Kubernetes is the standard runtime for cloud-native workloads. Most teams either manage their own clusters on a cloud provider or use a managed platform that runs Kubernetes on their behalf.
• PaaS and deployment platforms: Platform as a Service tools abstract Kubernetes and cloud provider complexity. Northflank's managed cloud deploys services, databases, workers, and jobs on production-grade Kubernetes infrastructure without requiring teams to provision or manage clusters. For teams with specific infrastructure requirements, Northflank also supports bring your own cloud (BYOC) across major cloud providers, bare-metal, and on-premises infrastructure.
• Observability: Datadog, Grafana, and OpenTelemetry-compatible tooling give teams metrics, logs, and traces across distributed cloud workloads.]

Most engineering teams running cloud development use a three-environment model: development, staging, and production. Each environment mirrors production infrastructure as closely as possible, reducing the gap between where code is tested and where it runs.

A typical GitOps workflow looks like this:

1. Engineers work on feature branches, each with its own preview environment provisioned on live infrastructure.
2. Pull requests trigger CI pipelines, where automated tests run against the preview environment.
3. On merge to the main branch, the staging environment updates.
4. After validation, a release pipeline promotes the build to production.

Preview environments are where cloud development workflows create the most immediate value. Reviewing a UI change or an API integration on a running environment (not a screenshot) reduces review cycles and catches integration issues before they reach staging.

Northflank's preview environments provision per branch, include databases and backing services, and tear down after the pull request closes.

Cloud development shifts spending from capital expenditure (servers, hardware) to operational expenditure (pay-per-use compute). The cost model is more flexible, but it introduces new drivers that are easy to underestimate.

Main cost drivers in a cloud development workflow:

• Compute: Running services, build pipelines, and databases continuously. Idle environments left running accumulate cost.
• Egress: Data transferred out of a cloud region is billed separately by most providers. Architectures that move large volumes of data between regions or services compound this.
• Storage: Persistent volumes, container image registries, and database storage all have per-GB pricing.
• Preview environments: Without a clear lifecycle policy, preview environments for closed pull requests continue to consume compute and storage.

Teams that instrument their cloud spend early (per-service cost allocation and idle resource policies) are in a much better position to optimise as they scale. For a detailed breakdown of cloud cost strategy, see Northflank's guide to cloud cost optimisation.

Cloud development is a broad term for using cloud infrastructure across the software delivery lifecycle. Cloud-native development is a specific approach to building applications using containers, microservices, declarative APIs, and CI/CD, so that they run efficiently on cloud platforms. All cloud-native development is cloud development, but not all cloud development is cloud-native.

The AWS CDK is an open-source framework for defining AWS cloud infrastructure using familiar programming languages including TypeScript, Python, and Java. It compiles to CloudFormation templates, letting engineers define infrastructure as code in the same languages they use for application code. It is an infrastructure provisioning tool, not a development environment.

Cloud development replaces per-machine environment setup with shared, declarative infrastructure that every engineer accesses consistently. Teams use the same environment definitions, run the same CI pipelines regardless of local machine configuration, and review changes against live preview environments rather than local builds. This reduces friction in onboarding, code review, and cross-team integration work.