Deployment and Cloud Servers: From Source Code to a Running Application

The short answer

Deployment is the controlled process of placing a specific version of an application and its required configuration into an environment where it can run and receive traffic.

Source code alone is not a running service. Depending on the application, deployment may resolve dependencies, run checks, compile or bundle code, produce an artifact or container image, start a process with runtime configuration, verify readiness, and route traffic to it.

Cloud services change who operates each layer. They do not remove the layers: code still executes in a process, on an operating system or managed runtime, using compute, memory, networking, and storage somewhere.

What deployment means

During development, one person may edit code, start a local process, use a local database, and open localhost. Production introduces a shared environment that must be repeatable, observable, secure, and reachable by real clients.

A deployment answers questions such as:

• Which version should run?
• What artifact represents that version?
• Which runtime and operating-system assumptions does it have?
• Which configuration and secrets belong to this environment?
• How does the platform know the process is ready?
• When and how does traffic move to it?
• How can an unhealthy release be stopped or rolled back?

Deployment can be manual or automated, but the boundaries exist either way.

Source code, build output, and artifacts

Source code is the human-maintained input: application files, manifests, lockfiles, and configuration templates. A build transforms or packages those inputs for execution or delivery. The result is a deployment artifact: for example, compiled binaries, bundled frontend assets, an archive with dependencies, or a container image.

Compiled applications may produce machine code or bytecode. JavaScript or Python applications may not compile in the same sense, yet they can still transpile, bundle, resolve locked dependencies, generate assets, or package files. A static frontend commonly becomes HTML, CSS, JavaScript, fonts, and images that a host or CDN can serve.

An artifact should identify what was tested and deployed. Rebuilding from changing dependencies during production startup can produce something different from the version that passed checks.

The runtime and application process

A runtime provides the machinery needed to execute an application: Node.js for JavaScript, a Java Virtual Machine for JVM bytecode, a Python interpreter, or native operating-system facilities for a compiled binary.

When the application starts, the operating system creates a process with memory, environment, files, permissions, and network access. That process may create several threads or use an event loop. It opens a listening socket or receives events through a managed platform.

A deployment can report that a process started even when the application cannot serve useful requests. Configuration may be invalid, a dependency may be unreachable, or initialization may still be running.

Operating systems, ports, and environment

An operating system schedules processes, manages memory and files, and exposes networking. A server application commonly listens on an IP interface and port, such as port 8080.

Listening on 127.0.0.1:8080 means only the same network host can normally reach that socket. Listening on an appropriate non-loopback interface can make it reachable from the surrounding container or network, subject to firewall and platform rules. Exact interfaces and security policy vary by environment.

The platform might provide the expected port through configuration. If the process ignores it and listens elsewhere, startup can appear successful while health checks and public traffic fail.

Development and production also differ in operating-system libraries, filesystem paths, case sensitivity, user permissions, clock settings, CPU architecture, and resource limits. Local success proves the code worked in one environment, not every target environment.

Physical machines and virtual machines

A physical server supplies processors, memory, network interfaces, and storage devices. Virtualization lets a hypervisor expose virtual hardware to one or more virtual machines. Each VM commonly runs its own guest operating-system kernel and processes.

Cloud providers let customers provision these virtualized resources through APIs. NIST defines cloud computing around on-demand network access to a shared pool of configurable resources that can be provisioned and released rapidly.The cloud model includes infrastructure, platform, and software service models rather than one required deployment topology.¹

Amazon EC2 is one provider-specific example. AWS defines an EC2 instance as a virtual server in its cloud.An EC2 instance is not a physical data center; it is a compute resource launched within AWS location and network boundaries.⁴

VM users commonly manage more of the operating system, patches, runtime, service manager, firewall, and application process than users of a higher-level managed platform.

Containers

A container image packages a filesystem and execution configuration. A container runtime creates an isolated process environment from that image using operating-system capabilities. The OCI Runtime Specification standardizes the configuration, execution environment, and lifecycle expected of compatible runtimes.An image specification and runtime specification solve related but different packaging and execution concerns.²

Containers commonly share a host kernel rather than booting a separate guest kernel for every application. That makes “a lightweight VM” a useful first impression but not a fully equivalent technical model. Docker describes containers as isolated processes with their required files and contrasts them with VMs that include separate operating systems.VMs and containers are also commonly used together.³

A container does not automatically make an application portable across every CPU architecture, kernel capability, network policy, filesystem expectation, or managed platform. It creates a more explicit package and runtime boundary.

Managed application platforms

A managed application platform accepts source or an artifact and operates more of the surrounding infrastructure. It may select a runtime, build the application, create instances, restart failed processes, terminate TLS, collect logs, and route traffic.

This resembles the platform-as-a-service boundary in NIST's cloud service models: the consumer deploys an application while the provider manages more of the network, servers, operating systems, and storage underneath.The exact division of responsibility is product-specific.¹

Managed does not mean unconfigured. The application still needs correct build commands, startup commands, ports, environment settings, health checks, resource sizing, and dependencies. The provider still runs underlying physical and virtual infrastructure even when the developer does not operate it directly.

Serverless execution

Serverless platforms run application functions or services in response to requests or events while the provider manages capacity and execution infrastructure. AWS Lambda Functions are one vendor example that runs code in response to events or API calls while AWS manages the execution infrastructure.Other products and providers use different lifecycle, runtime, concurrency, and billing models.¹⁰

“Serverless” means the application team does not manage servers in the same way; it does not mean that no servers exist. Processes may be created, reused, paused, or replaced under provider rules. Startup latency, execution limits, stateless instances, networking, and external persistent storage still matter.

Static frontend hosting is another distinct model: prebuilt assets can be served from object storage or an edge network without running application backend code for each request. The frontend and backend can be deployed separately and can use several models together.

Configuration and secrets

Configuration supplies environment-specific values: port, database address, allowed origins, log level, service URLs, feature policy, and credentials. Build-time values are embedded while producing an artifact; runtime values are supplied when a process starts or while it runs. Confusing the two can deploy stale or exposed values.

Environment variables are one configuration mechanism, not a complete secrets system. They can be inherited by processes, exposed in diagnostics, or included accidentally in logs and dumps. Secrets such as database passwords, API keys, signing keys, and certificates require controlled storage, delivery, access, rotation, and auditing.

OWASP warns against hardcoding secrets in source or container definitions and describes managed stores, mounted files, and runtime injection as possible delivery patterns.The correct mechanism depends on the target platform and threat model.⁸

Dependencies and database connectivity

A running backend may still depend on a database, cache, queue, object store, or external API. Production failures often come from the boundary between the application and those services:

• the hostname or port belongs to another environment;
• network policy blocks the connection;
• credentials lack permission or have expired;
• TLS trust or service identity is wrong;
• a schema migration has not run;
• connection limits or timeouts differ from local development.

Databases are commonly operated separately from application processes so their persistence, backups, availability, and scaling can be managed independently. A container image should not be treated as durable database storage merely because data exists inside its writable filesystem while it runs.

Domains, TLS, and traffic routing

After the application is healthy internally, public traffic still needs a path:

1. DNS gives clients destination information.
2. A CDN, load balancer, gateway, or reverse proxy may accept the connection.
3. TLS credentials must cover the requested service identity.
4. Routing rules must select the intended deployment.
5. Network policy must allow the next hop.
6. The application must listen on the expected interface and port.

Not every architecture includes every component. A small VM can terminate TLS and run the application directly. A larger platform may terminate TLS at an edge service and create several private hops before an application instance.

Deployment success and public reachability are therefore different claims.

Health checks and deployment readiness

A startup check can allow initialization to finish. A readiness check asks whether an instance should receive traffic. A liveness check asks whether the platform should restart a stuck or irrecoverable instance.

Kubernetes documents these as separate probes: failed readiness removes a Pod from Service traffic while the container continues running; liveness can trigger a restart; startup can delay the other probes for slow initialization.These names are Kubernetes-specific, but the responsibility distinction applies more broadly.⁵

A process can be alive but not ready because its database is unavailable or required configuration has not loaded. Conversely, making liveness depend on every downstream service can create restart loops during a dependency outage. Health endpoints need deliberate semantics and inexpensive, bounded checks.

This flow is qualified. An interpreted application may package rather than compile. A managed platform may perform several steps. Static hosting may publish assets without starting a long-running application process.

Regions, Availability Zones, and data centers

Cloud geography is provider terminology, so use the provider's definitions:

• A region is a broad geographic area in which resources are provisioned.
• An Availability Zone is an isolated location within a region under a provider's design.
• A data center is a physical facility housing computing and network equipment.

In AWS's model, a region contains multiple Availability Zones, and an Availability Zone consists of one or more discrete data centers.An Availability Zone should not be described universally as exactly one building.⁶

Deploying across zones can reduce exposure to one location failure, but it does not automatically make an application highly available. Traffic distribution, database topology, capacity, state, and failure testing must also support the design.

CDNs and edge locations

An edge location is a provider-defined site closer to users that offers selected edge services. A CDN can cache static or eligible dynamic responses there, terminate connections, apply policy, or forward requests to an origin.

For CloudFront, AWS describes points of presence—also called edge locations—that serve content to viewers, with regional edge caches between those locations and an origin in applicable request paths.Do not assume that every edge location runs the complete application. Other CDNs use their own topology and terms.⁷

Scaling at a high level

Vertical scaling gives one instance more CPU, memory, or other capacity. Horizontal scaling runs more instances and distributes work among them.

Horizontal scaling requires shared assumptions to be explicit. Session state in one process, files written to one instance, scheduled jobs, database connection counts, and cache invalidation can behave differently with several replicas.

Autoscaling changes capacity based on signals or schedules. It cannot compensate for an inefficient query, a hard database limit, or an unavailable dependency without moving the bottleneck.

Deployment strategies at a high level

• A rolling deployment replaces instances in portions, so old and new versions may run together.
• A blue-green deployment prepares a separate environment and then moves traffic between the old and new environments.
• A canary deployment first sends a limited share of traffic to the new version and expands it after observation.
• A rollback restores a previously known version or routes traffic back when the release fails its acceptance criteria.

AWS's deployment guidance documents these patterns as examples and notes their different infrastructure, traffic, and rollback behavior.They are general techniques, not AWS-only requirements.⁹

Database migrations, queues, caches, and external contracts can make rollback more complex than selecting an older artifact. Compatibility must be planned before traffic moves.

Why applications work locally but fail in production

Common differences include:

• missing or incorrect runtime configuration;
• secret or permission errors;
• a process listening on the wrong port or interface;
• different runtime, operating-system, or CPU versions;
• case-sensitive paths or missing build files;
• blocked database or external-service connections;
• production origins rejected by CORS or redirect allowlists;
• proxy timeouts or request-size limits;
• insufficient memory or file permissions;
• a health check that exercises the wrong path.

“Works locally” is evidence about the code in the local environment. Reproduce production inputs and boundaries before deciding which layer is defective.

Common misconceptions

Debugging scenario

Knowledge check

What to learn next