What is a deployment?

Writing code that works on your computer is one thing. Making it work for other people, around the clock, on another machine, is another. A deployment is the bridge between the two.

In practice it becomes a routine you repeat dozens of times: change the code, deploy, the change goes live. Understanding what happens inside that routine helps you find errors faster and pick better tools.

What is a deployment?#

A deployment is the set of steps that takes a specific version of your code to an environment where it runs and can be reached. The environment is usually a server, a VPS, a container or a hosting platform.

A deployment has a clear start and end: it begins with a commit (or a folder of files) and ends with the application process running and verified. If you end up with an app that responds, the deployment worked. If the process crashes on startup, it failed, even when every file arrived.

Do not confuse it with hosting. Hosting is the place; deploying is the act of putting something there. To understand the place, see VPS vs cloud platform.

Which environments exist?#

Almost every serious project has more than one environment, and you deploy to each:

• Development: your machine. Run and break things freely.
• Staging: a copy as close to production as possible, used to test before release.
• Production: what real users use. This is where a mistake costs the most.

Small projects, like a personal bot, often have only development and production. That works if you test locally with care and know how to go back (below).

What happens when you deploy?#

The Twelve-Factor App methodology splits the process into three stages, a good mental model:

1. Build: turns the code from a commit into something executable. It fetches dependencies and compiles what needs compiling.
2. Release: combines the build with the environment's configuration (variables, keys, database addresses). The result is ready to execute.
3. Run: starts the app's processes using a chosen release.

In practice, the steps you see are these:

1. The code reaches the server (upload, git pull, container image).
2. Dependencies are installed (npm ci, pip install -r requirements.txt).
3. If the language needs it, the code is compiled (TypeScript, Go, Rust, Java).
4. Configuration is applied.
5. The old process is stopped and the new one starts.
6. You check that it works by reading the logs and testing a route or a command.

Each step fails for a different reason. A dependency that will not install is a build problem. A missing variable is a release problem. A process that exits right after starting is a run problem. Knowing which stage broke already cuts the diagnosis in half.

That is why build and configuration stay separate. What changes between environments (a token, a database URL) does not live inside the code: it comes in through environment variables, so the same code runs on staging and production unchanged.

What are the ways to deploy?#

Manual#

You copy files to the server (SFTP, scp, an upload panel) and restart the process. It is simple and fine for learning. The cost is that the result depends on the person's memory: a forgotten file, a step out of order.

Through Git#

You run git push and the server pulls the new code and runs the steps. Git history becomes your version record, and each deployment maps to an identifiable commit.

With CI/CD#

CI (continuous integration) runs tests on every change. CD (continuous delivery or deployment) carries the approved result to the environment. Tools like GitHub Actions run this pipeline on every push. The gain is that the path is always the same, and a commit with a failing test never reaches production.

This GitHub Actions pipeline runs a Node.js project's tests on every push to main:

name: ci
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: lts/*
      - run: npm ci
      - run: npm test

The publish step would come after npm test and run only if the tests passed. How you publish depends on your provider; the full walkthrough is in automatic deploys with GitHub Actions.

With containers#

You package the app and its dependencies in an image, and deploying becomes "run this image". This reduces the classic "it works on my machine". See what is Docker.

What do you do when a deployment goes wrong?#

Nobody gets it right every time. What separates a small incident from a big one is how fast you can go back.

• Rollback: return to the previous version. The Twelve-Factor App lists rolling back to a previous release as a typical capability of deployment tools. With Git, the previous version is the previous commit: deploy it again.
• Read the logs first. The error message usually points to the stage (build, configuration or run).
• Change one thing at a time. A deployment carrying five changes is hard to debug.
• Back up your data before risky changes, especially database migrations. Code is recoverable through Git; data is not.

Common mistakes: forgetting an environment variable in production, using a different runtime version than locally, relying on a file listed in .gitignore that never reaches the server, or hardcoding a port instead of reading the one the platform provides.

Which terms go along with deployment?#

• Pipeline: the automated sequence of stages (test, build, publish).
• Artifact: the output of the build (a package, an image).
• Downtime: time the app is unavailable. If the old process stops before the new one starts, there is a short gap. Strategies such as blue-green and rolling updates exist to reduce it, but they need infrastructure that supports them.
• Ephemeral environment: an environment created for one task and discarded afterward.
• Hotfix: an urgent fix sent straight to production.

How to do this on Square Cloud#

On Square Cloud, the stages in this guide stay visible and under your control. Your code arrives by ZIP upload in the dashboard, the CLI, GitHub (a push deploys, through the official GitHub Action or a webhook) or the VS Code extension. The platform has no build step: on start, it installs dependencies (npm install for Node.js when there is no node_modules, pip install -r requirements.txt for Python), and the install output shows up in the application's logs. If your project needs compiling, run the build in CI and upload the result, or put the build in the start command.

Configuration comes in through environment variables, set per application, and a change takes effect on the next restart, with no need to upload the code again. The squarecloud.app file (name, main file, memory, version) is optional: the dashboard generates it at deploy time, or you write it at the project root. Among several runtimes, such as Node.js, Python, Go and Java, there is also TypeScript with no build step; see the runtimes available today on Runtimes.

For a way back, take a manual snapshot before a risky change: snapshots are available on every plan and restore the whole application. See the deployment options in features and how snapshots work.