What is Deployment?

Deployment is the process of taking software, configuration or infrastructure changes and making them available in a target environment where they can run. That target might be a test server, staging environment, production cloud platform, container cluster, virtual machine, edge device or a user's computer. The key distinction is that deployment changes what is installed or running in an environment. It is not automatically the same thing as releasing a feature to users.

A deployment can be manual or automated, small or complex, local or remote. Modern software teams commonly use repeatable pipelines to build, test, package, deploy, verify and monitor changes, because the deployment itself is only one part of getting software safely from source code into operation.

The infographic below shows the deployment workflow, common target environments and the main decisions that affect reliability.

How does software deployment work?

The exact process depends on the application and platform, but deployment normally moves a known version of software and its required configuration into a defined target environment. A robust process also checks that the new version is healthy after the change rather than assuming success because files copied or an API returned a successful response.

1. Build or package the software into a deployable artefact such as an application package, binary, container image or static site bundle.

2. Run automated tests and other checks against the version that is intended for deployment.

3. Prepare the target environment, including configuration, secrets, dependencies, database changes and infrastructure where required.

4. Deploy the artefact or apply the change to the target environment.

5. Verify health checks, logs, application behaviour and critical user journeys.

6. Monitor the new version and roll back, roll forward or remediate if the deployment causes a problem.

Deployment environments: development, test, staging and production

Deployment does not mean production only. Software is often deployed repeatedly as it moves through different environments. Microsoft describes a common multi environment architecture with development, test, staging and production, with staging intended to mirror production as closely as practical before the live deployment.

• Development: where engineers build and initially test changes.

• Test: where automated or human testing validates behaviour away from production users.

• Staging: a production like environment used for final validation before release.

• Production: the live environment used by real users and systems.

The underlying environment may run on cloud platforms, virtual machines, physical servers or container infrastructure.

Deployment vs release: what is the difference?

Deployment and release are related but not identical. Deployment puts a software version into an environment. Release makes functionality available to its intended users. A team can deploy code to production while keeping a new feature disabled behind a feature flag, then release it later without another deployment. Equally, a traditional process may deploy and release at the same moment.

Separating deployment from release can reduce operational risk because the technical act of changing production and the business decision to expose a feature do not have to happen simultaneously.

What is continuous deployment?

Continuous deployment is the practice of automatically publishing and deploying software updates after the required automated checks pass. GitHub's continuous deployment documentation describes a typical CD process in which code is automatically built and tested before deployment.

Continuous deployment should not be confused with continuous delivery. In common DevOps usage, continuous delivery keeps changes in a deployable state but may retain a manual approval before production, while continuous deployment removes that routine manual production gate when the pipeline criteria are satisfied. Individual organisations may use the terminology differently, so the actual pipeline behaviour matters more than the label.

Common deployment strategies

• Recreate deployment: stop or replace the old version and then start the new version. It is simple but can create downtime.

• Rolling deployment: replace instances gradually so old and new versions coexist during the rollout.

• Blue green deployment: maintain two production capable environments and switch traffic from the current version to the new version after validation.

• Canary deployment: expose a new version to a small proportion of production traffic first, monitor it, then increase exposure if it behaves correctly.

• Feature flag release: deploy code while controlling whether specific functionality is exposed to users. This separates deployment from release.

Kubernetes documents canary deployment as running a new version alongside the stable version and sending a smaller share of production traffic to it before completing the rollout. This allows teams to observe real behaviour and roll back if problems appear. See the Kubernetes canary deployment guide for a concrete implementation example.

What can actually be deployed?

• Web applications and websites.

• Backend services and APIs.

• Mobile and desktop application packages.

• Container images and containerised services.

• Serverless functions.

• Database schema changes and migrations.

• Infrastructure as code definitions.

• Configuration and policy changes.

• Machine learning models.

• Software and firmware for remote or edge devices.

Container based deployment is particularly common because a container image can package an application with much of its runtime environment. See What is Container? and What is Docker? for the underlying concepts.

Deployment and broadband: when does connection speed matter?

Deployment itself is a software lifecycle process, but the network can become a practical constraint when large artefacts, container images, dependencies or updates must cross a broadband or WAN connection. Upload speed matters when a developer or on premises build system sends data to a remote platform. Download speed matters when target machines pull packages or container layers from a remote registry.

The end to end path matters. A 1 Gbps broadband service cannot make a deployment transfer run at 1 Gbps if the local Ethernet interface, WiFi link, VPN, remote registry, storage system or target platform is slower. Likewise, latency can affect workflows involving many sequential requests even when the total data volume is small.

Techie Broadband calculation: transferring a 2 GB deployment artefact

Consider a theoretical 2 GB decimal deployment artefact that must be uploaded to a remote platform. Two gigabytes equals 16 gigabits, or 16,000 megabits.

• At 100 Mbps upload: 16,000 Mb ÷ 100 Mb/s = 160 seconds, or 2 minutes 40 seconds.

• At 500 Mbps upload: 16,000 Mb ÷ 500 Mb/s = 32 seconds.

• At 1 Gbps upload: 16 Gb ÷ 1 Gb/s = 16 seconds.

• At 2.5 Gbps upload: 16 Gb ÷ 2.5 Gb/s = 6.4 seconds.

These are theoretical transfer times, not promises. Real deployments can take longer because of protocol overhead, encryption, compression, file count, storage speed, server limits, contention, latency, validation and the deployment platform itself. Container registries may also reuse layers that already exist remotely, so a deployment does not necessarily transfer the full nominal image size every time.

How deployment uses containers and virtual machines

A virtual machine deployment may create or update a complete guest operating system environment. A container deployment normally schedules one or more container images onto hosts that share the host kernel. Both can be automated, but their packaging, isolation, startup behaviour and resource model differ.

Deployment tooling should therefore be understood separately from the runtime technology. Kubernetes, for example, manages containerised workloads and their desired state, while a CI/CD system can decide when a particular version should be delivered to that platform.

Configuration, secrets and dependencies

Deploying application code is only part of a production change. The software may depend on environment variables, certificates, API credentials, database connections, DNS records, network policies, runtime versions and external services. A deployment can fail even when the application artefact itself is correct if one of those dependencies is missing or incompatible.

Remote administration may also use SSH, while deployed services frequently communicate through APIs. These are supporting technologies, not deployment strategies themselves.

Why rollback planning matters

A deployment is not safe merely because it can be automated. Teams need a recovery path when a new version causes errors, performance degradation or incompatibility. A rollback restores a previous known version, while a roll forward deploys a corrective change. Database migrations deserve particular care because a code rollback may not automatically reverse a data or schema change.

• Keep deployable versions identifiable and reproducible.

• Define health checks and success criteria before the rollout.

• Know which changes are backwards compatible.

• Back up or protect state that cannot simply be recreated.

• Test rollback or recovery procedures rather than assuming they work.

• Monitor application errors, latency, resource usage and user facing availability after deployment.

Deployment security

Deployment pipelines can hold powerful credentials and can modify production systems, so they are security sensitive. Access should follow least privilege, secrets should not be embedded in source code or logs, artefacts should be traceable to their source, and production changes should be auditable. The exact controls depend on the platform and risk model.

Automating a weak process does not make it secure. A fast pipeline that can deploy unreviewed or untrusted artefacts simply makes unsafe changes happen faster.

Common deployment problems

• The application works in development but fails because production configuration differs.

• A dependency or runtime version is missing on the target system.

• A database migration is incompatible with the new or old application version.

• The deployment succeeds technically but health checks or user journeys fail.

• DNS, certificates, firewall rules or network policy prevent the service being reached.

• The target cannot download an image or package because registry access fails.

• Insufficient CPU, memory, storage or disk I/O causes the new version to become unhealthy.

• A rollout replaces too much capacity at once and creates an availability problem.

• Monitoring is too weak to detect a bad deployment quickly.

How to troubleshoot a failed deployment

1. Identify exactly which stage failed: build, test, package, transfer, installation, startup, health check or post deployment validation.

2. Check the deployment logs and the application logs rather than relying only on a generic failed status.

3. Confirm that the exact artefact or image version intended for deployment reached the target.

4. Compare environment configuration, secrets, runtime versions and dependencies with the known working environment.

5. Check DNS, routing, firewall, certificates and registry or package repository access if remote resources cannot be reached.

6. Verify available CPU, memory, storage and disk performance on the target.

7. Check database migration status and compatibility if the application starts but fails on data operations.

8. Test the application's health endpoint and a critical user journey.

9. Roll back or roll forward according to the recovery plan if the production impact is unacceptable.

10. After recovery, record the root cause and add a test or guardrail that can catch the same failure earlier next time.

Deployment at the edge

Deployment becomes more complicated when software must reach many remote locations or devices. Edge computing can place applications close to users or data sources, but teams then need to consider intermittent connectivity, version drift, remote recovery and the bandwidth required to distribute updates across a fleet.

Deployment FAQs

Is deployment the same as installation?

Installation is one possible part of deployment. Deployment is broader and can include packaging, configuration, infrastructure changes, rollout strategy, verification, monitoring and recovery.

Is deployment the same as release?

No. Deployment changes what software is present or running in an environment. Release makes functionality available to users. They can happen together, but they do not have to.

Does every deployment cause downtime?

No. Rolling, blue green and canary strategies can maintain service while a new version is introduced, provided the application and infrastructure are designed to support that strategy. Zero downtime should not be assumed without testing.

What is a production deployment?

A production deployment places a software or infrastructure change into the live environment used by real users or systems. Because the impact is real, production deployments normally need stronger controls, monitoring and recovery planning than development deployments.

Can deployment be fully automated?

Yes, many deployment workflows can be automated from build through production. Whether they should be fully automatic depends on the organisation's risk, testing quality, compliance requirements and release process.

Key takeaway

Deployment is the controlled process of moving software and related changes into an environment where they can run. Good deployment is not just copying files to a server. It combines a reproducible artefact, the right configuration, a suitable rollout strategy, verification, monitoring and a recovery plan. For remote and cloud deployments, broadband and network performance can affect transfer time, but the reliability of the complete software and infrastructure path is what determines whether the deployment actually succeeds.

To explore the related technical concepts used in this Deployment guide, visit our broadband terminology guide.