How to Set Up CI/CD: From GitHub Repository to Automated Server Deploymen

Manual deployment works well during the early stages of development: a developer connects to the server, uploads a new version of the project, installs dependencies, and restarts the application. As the project grows, however, this process quickly becomes a source of errors.

You might forget to run a database migration, install the wrong dependency version, deploy code from the wrong branch, or simply skip one of the required steps. On top of that, every release starts consuming more developer time.

CI/CD solves this problem by automating the process of testing, building, and delivering changes to a server with minimal manual intervention.

In a simple setup, a developer only needs to push changes to the main branch:

The CI/CD system can then automatically:

1. retrieve the source code;
2. install dependencies;
3. run tests;
4. build a Docker image;
5. publish it to a container registry;
6. connect to the server;
7. download the new application version;
8. restart the container.

In this guide, we will build this pipeline from scratch. We will use GitHub and GitHub Actions for source control and CI/CD, package the application with Docker, store container images in Docker Hub, and deploy the production environment to an Ubuntu VPS.

The final architecture will look approximately like this:

Deploy a Server for CI/CD with Serverspace

An automated pipeline ends where your production infrastructure begins. To build a complete CI/CD workflow, you need a server that remains available online and can receive new application versions automatically.

With Serverspace, you can deploy a cloud VPS and use it as a production environment for a website, API, backend service, or another application.

Ubuntu is a practical starting point for CI/CD infrastructure. You can select the amount of CPU, RAM, and SSD storage required by your workload and scale the configuration as the project grows.

A VPS can host:

• Docker containers;
• backend applications;
• REST APIs;
• Node.js, Python, PHP, and other runtimes;
• Nginx;
• PostgreSQL and other databases;
• staging and production environments;
• self-hosted CI/CD tools.

For the project in this guide, an Ubuntu VPS with a public IP address and SSH access is enough.

Deploy a VPS in Serverspace, choose Ubuntu, and use it as the destination for your automated deployment pipeline.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry

What Is CI/CD?

CI/CD combines several development automation practices.

CI stands for Continuous Integration.

Its purpose is to automatically validate code changes before they reach production.

After every push or pull request, the CI system can:

• install dependencies;
• run a linter;
• execute unit tests;
• execute integration tests;
• build the application;
• verify that the Docker image can be built successfully.

CD can mean either Continuous Delivery or Continuous Deployment.

With Continuous Delivery, a release-ready version is automatically tested and prepared, but deployment to production still requires manual approval.

With Continuous Deployment, every change that successfully passes the pipeline is automatically deployed to production without an additional manual step.

The difference can be summarized as follows:

Approach	What Is Automated	Production Deployment
Continuous Integration	Builds, checks, and testing	Not necessarily included
Continuous Delivery	Preparing a release-ready build	After approval
Continuous Deployment	The full path from commit to production	Automatic

In this guide, we will implement the third approach: after a successful merge or push to main, the new version will automatically be deployed to the server.

CI/CD Pipeline Components

Our example uses five main components.

GitHub

The Git repository acts as the source of the application code and triggers the pipeline when changes are pushed.

GitHub Actions

GitHub Actions runs CI/CD jobs on dedicated runners.

This is where tests, Docker image builds, and deployment steps will execute.

Docker

Docker packages the application, runtime, and dependencies into a portable container image.

Instead of manually installing each new version on the server, the CI/CD pipeline can simply replace the old container with a new one.

Docker Hub

The container registry stores built Docker images.

GitHub Actions publishes the new image to Docker Hub, while the production server downloads the required version.

If necessary, you can replace Docker Hub with GitHub Container Registry, GitLab Container Registry, or your own private registry.

Ubuntu VPS

The server runs Docker Compose, which starts the required application version.

Prerequisites

To follow this guide, you will need:

• a GitHub repository containing your project;
• a Docker Hub account;
• an Ubuntu VPS;
• SSH access to the server;
• a Dockerfile for the application;
• a command that runs your project tests.

We will use a Node.js project for demonstration purposes.

However, the overall architecture is largely independent of the programming language.

For example, the CI stage can use different commands depending on the stack:

Stack	Install Dependencies	Run Tests
Node.js	npm ci	npm test
Python	pip install -r requirements.txt	pytest
PHP	composer install	phpunit
Go	go mod download	go test ./...

Once the tests are complete, the remaining stages — Docker build, registry publication, and deployment — can stay almost identical.

Step 1. Prepare the Git Repository

If the project is not yet tracked by Git, initialize the repository:

Add the files:

After creating the remote repository on GitHub, connect it:

Replace USERNAME and PROJECT with your GitHub account and repository names.

For CI/CD, production deployment should only be triggered from a controlled branch.

A common branch structure is:

• main — production;
• develop — integration branch;
• feature branches — individual development tasks.

For a small project, main plus feature branches is often enough.

The workflow can look like this:

This way, a regular pull request triggers validation but does not modify production.

Step 2. Add a Dockerfile

Create a file named:

in the root of the repository.

For a simple Node.js application, it can look like this:

Here:

• FROM defines the base image;
• WORKDIR creates the working directory;
• COPY adds project files to the image;
• npm ci installs dependencies;
• EXPOSE documents the application port;
• CMD starts the application.

The exact Dockerfile will depend on your application stack.

For production workloads, you can also use multi-stage builds to separate the compilation environment from the final runtime image.

Step 3. Create a .dockerignore File

You generally should not copy the entire development directory into the Docker image.

Create:

For example:

It is especially important to exclude .env and other files containing secrets.

Passwords, API keys, and production configuration should never be baked into the Docker image.

Step 4. Test the Docker Image Locally

Before adding CI/CD automation, make sure the project can be built manually.

Run:

Start the container:

The application should now be available at:

(http://localhost:3000[/code)]

If the local Docker build does not work, CI/CD automation will not fix it.

Your pipeline should automate an already working build and deployment process, not replace one.

Step 5. Prepare the Ubuntu Server

Connect to the VPS:

Update the system:

Install the required packages:

Create a directory for APT keys:

Add the key for Docker's official repository:

Add the Docker repository:

Refresh the package index:

Install Docker Engine and Docker Compose:

Check the Docker service:

Check the Docker Compose version:

Step 6. Create a Dedicated Deployment User

It is not recommended to give your CI/CD pipeline permanent SSH access through the root account.

Create a separate user:

Add it to the Docker group:

Create the application directory:

Now exit the root session and reconnect as the new user:

Check Docker access:

If the command works without sudo, the user is ready for deployment.

Step 7. Configure an SSH Key for GitHub Actions

GitHub Actions must be able to connect to the server without entering a password interactively.

On your local machine, create a dedicated SSH key pair:

This creates two files:

The first file contains the private key.

The second contains the public key.

Add the public key to the server:

Alternatively, add its contents manually to:

Test the connection:

We will add the private key to GitHub Secrets later.

Do not commit it to your Git repository.

Create a Production Environment in Serverspace for Automated Deployment

Once the pipeline is configured, the server becomes a permanent part of your development workflow.

Instead of manually uploading every release, the CI/CD system connects to the VPS and updates the containers automatically.

With Serverspace, you can start with a small virtual machine and increase CPU, RAM, or storage as application requirements grow.

A production environment can also be divided into several components:

This allows you to keep the same CI/CD pipeline even when moving from a single VPS to a more complex infrastructure.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry

Step 8. Create the Docker Compose Configuration

Go to the application directory:

Create:

Add:

Replace:

with the name of your Docker Hub repository.

Pay attention to:

This variable allows the server to run a specific Docker image associated with a particular commit instead of always using only the latest version.

We will use this capability for rollback.

Step 9. Add Application Environment Variables

Production secrets are better stored on the server rather than inside the Docker image.

Create:

For example:

Restrict file permissions:

The app.env file does not need to be stored in GitHub.

This allows you to build the same Docker image and use different configuration values in staging and production.

Step 10. Configure Docker Hub

Create a repository in Docker Hub.

For example:

For CI/CD, use an access token instead of your primary account password.

If the repository is private, authenticate the production server once:

After successful authentication, the server will be able to run:

If the repository is public, separate authentication is generally not required for pulling the image.

Step 11. Add GitHub Secrets

Open the GitHub repository and go to:

Create the following repository secrets:

Secret	Value
DOCKERHUB_USERNAME	Docker Hub username
DOCKERHUB_TOKEN	Docker Hub access token
SERVER_HOST	Production server IP address or domain
SERVER_USER	For example, deploy
SERVER_SSH_KEY	Contents of the private github_actions_deploy key
SERVER_HOST_KEY	SSH host key of the server

You can retrieve the host key with:

Add the resulting line to SERVER_HOST_KEY.

For a production environment, verify the server fingerprint through a trusted channel before storing the host key. Avoid blindly accepting any SSH host key during deployment.

Step 12. Create the GitHub Actions Workflow

Create the following directory in your repository:

Inside it, create:

Add the following workflow:

This is already a complete CI/CD pipeline.

Now let's break down how it works.

How the on Section Works

The workflow starts on two events:

A pull request targeting main starts CI.

A push to main starts CI and, if the tests succeed, continues with the build and deployment jobs.

This separation is important.

Simply opening a pull request should not automatically change the production environment.

How the test Job Works

The first job is:

It runs for both pull requests and pushes.

GitHub creates a temporary runner:

It then checks out the repository:

Sets up Node.js:

Installs dependencies:

And runs the test suite:

If any command exits with a non-zero status code, the job fails.

The following stages will not start.

This is the point where CI prevents an obviously broken version from reaching production.

How the Docker Build Works

The next job depends on the test job:

It also uses the following condition:

As a result, the Docker image is published only after an actual change reaches main.

The pipeline authenticates with Docker Hub:

It then creates two tags:

For example, the registry might contain:

The latest tag provides a convenient pointer to the newest build.

SHA tags make it possible to associate every image with a specific Git commit.

We will use SHA tags for production deployment.

Why Deploy by Commit SHA Instead of latest?

Consider the following example.

On Monday, you deploy commit:

On Tuesday, you deploy:

After the second deployment, a problem appears.

If the server only uses:

it may not be immediately obvious which exact image version was running before the update.

With SHA tags:

each version can be identified unambiguously.

That is why the workflow writes the current commit SHA to:

For example:

Docker Compose uses this value here:

This keeps the production environment tied to a specific Git commit.

How SSH Deployment Works

The final job only runs after a successful build:

GitHub Actions prepares the SSH configuration and runs:

On the remote server, the pipeline moves to:

It records the image tag:

Then runs:

Docker downloads the new image.

After that:

Docker Compose recreates the application container using the new version.

The developer no longer needs to manually connect to production for every release.

The Complete Path of a Code Change

Now let's look at the full workflow.

The developer creates a branch:

Makes changes and pushes them:

After a pull request is opened:

If all checks succeed, the pull request can be merged into main.

After the merge:

Everything after the merge happens automatically.

Step 13. Verify the First Deployment

After merging, open:

You should see three jobs:

They should complete successfully in sequence.

Then connect to the server:

Check the running container:

The output should look similar to:

Check the saved deployment tag:

For example:

To view application logs:

How to Add Nginx

A production application is usually not exposed directly to the internet through the Node.js application port.

Our Compose configuration uses:

This means port 3000 is only accessible locally on the server.

You can place Nginx in front of the application.

Install it:

Create a configuration:

Example:

Enable it:

Test the configuration:

Reload Nginx:

The production architecture now looks like this:

For a production website, the next step is usually to configure HTTPS.

How to Roll Back a Deployment

Automating deployment does not eliminate the possibility of a bad release.

For example:

• your tests may not cover a specific scenario;
• an external API may have changed;
• an error may only appear with production data;
• a performance regression may occur.

Suppose the current version is:

and the previous stable version is:

To roll back, connect to the server:

Go to the application directory:

Set the previous image tag:

Pull the image:

Restart the application:

Production will now run the previous version again.

This is why immutable tags based on commit SHA are more useful for production than relying only on latest.

Add a Health Check After Deployment

Successfully starting a container does not guarantee that the application is actually responding to requests.

You can add an automated endpoint check after deployment.

For example, if the application provides:

add the following step after SSH deployment:

The endpoint might return:

and, for example:

If curl receives an error response, GitHub Actions marks the job as failed.

In a more mature CI/CD pipeline, this step can also trigger an automatic rollback.

Separate Staging and Production

Deploying every change directly to production is not suitable for every project.

A safer workflow looks like this:

You can use two separate servers or two independent environments for this setup.

For example:

Branch	Environment	Address
develop	Staging	staging.example.com
main	Production	example.com

Each environment can use separate SSH credentials and GitHub Secrets.

Add Manual Approval Before Production Deployment

Continuous Deployment is not always the right choice.

For business-critical applications, it can be safer to automate:

• testing;
• building;
• publishing the Docker image;

while still requiring manual approval before production deployment.

In GitHub Actions, you can create a separate Environment:

and configure protection rules for it.

Then add the environment to the deployment job:

The pipeline will stop before production and continue after the configured approval requirements are satisfied.

This effectively turns Continuous Deployment into Continuous Delivery.

Do Not Store Secrets in the Repository

One of the most serious CI/CD mistakes is storing credentials directly in the workflow YAML.

Do not do this:

Even a private repository is not an appropriate place for secrets.

Use:

• GitHub Secrets;
• Environment Secrets;
• a dedicated secret manager;
• a production .env file with restricted permissions;
• separate CI/CD credentials.

You should also avoid using the same SSH key for both a developer's personal access and automated deployment.

Restrict Deployment User Permissions

The deployment pipeline should only have the permissions it actually requires.

In our example, the deploy user needs:

• SSH access;
• access to /opt/myapp;
• permission to manage Docker.

CI/CD should not receive direct root access unless it is genuinely required.

For stricter environments, you can further restrict:

• allowed SSH commands;
• network access;
• sudo permissions;
• access to other directories;
• access to the production database.

Keep in mind that membership in the Docker group effectively gives a user broad control over the host. Infrastructure with stricter security requirements should use an even more restrictive deployment model.

Do Not Deploy When Tests Fail

One of the main benefits of a CI/CD pipeline is the dependency between its stages.

The correct process looks like this:

Deployment should never run independently of CI results.

In GitHub Actions, this dependency is implemented with:

and:

What Else Can You Add to CI?

Our example only runs application tests, but a production CI pipeline can include many more checks.

For example:

Depending on the project, you might add:

• ESLint;
• Prettier;
• TypeScript compilation;
• pytest;
• PHPUnit;
• SonarQube;
• SAST;
• dependency scanning;
• Docker image scanning;
• dependency license checks.

The earlier a pipeline detects a problem, the cheaper and easier it is to fix.

How to Handle Database Migrations

Deployment becomes more complicated when a new application version requires changes to the database schema.

You cannot simply replace the container if the new code expects a table or column that does not exist yet.

One possible workflow is:

For example, before starting the new version, you might run:

For a Python project:

Production migrations require extra care.

Ideally, schema changes should remain compatible with both the new and previous application versions during the transition period.

Otherwise, rolling back only the application container may no longer be possible.

How to Prevent Concurrent Production Deployments

Suppose two commits reach main almost simultaneously.

Without additional protection, two deployment jobs could start at the same time.

Our workflow avoids this with:

GitHub will not run multiple jobs from the same production concurrency group simultaneously.

This is especially important if your deployment pipeline includes:

• database migrations;
• long-running deployment scripts;
• restarting multiple services;
• database operations.

How to Reduce Deployment Downtime

A regular:

deployment can create a short gap between the old container stopping and the new one becoming ready.

For smaller applications, this may be acceptable.

If the project requires near-zero downtime, you can move to more advanced deployment strategies.

For example:

Blue-Green Deployment

The new version is launched in parallel with the old one.

After verification, the load balancer routes users to Green.

If a problem occurs, traffic can immediately be switched back to Blue.

Another approach is a Rolling Update, where application instances are replaced gradually.

These strategies are commonly used with Kubernetes.

When Docker Compose Is No Longer Enough

Docker Compose works well for:

• small production projects;
• personal services;
• MVPs;
• backend applications;
• several related containers;
• staging environments.

As your infrastructure grows, you may need:

• multiple application nodes;
• automatic recovery;
• rolling updates;
• autoscaling;
• service discovery;
• load balancing;
• centralized secret management.

At that point, Kubernetes may be the next step.

The overall CI/CD concept remains almost the same:

The main difference is the final deployment stage.

GitHub Actions Is Not the Only CI/CD Option

The architecture described in this guide is not tied to GitHub.

Instead of GitHub Actions, you can use:

• GitLab CI/CD;
• Jenkins;
• TeamCity;
• CircleCI;
• Bitbucket Pipelines;
• Azure Pipelines;
• self-hosted runners.

In most cases, the workflow remains conceptually similar:

Understanding the CI/CD architecture itself is therefore more important than learning the syntax of any single platform.

Common CI/CD Setup Errors

Permission denied (publickey)

GitHub Actions cannot connect to the server:

Check:

• the contents of SERVER_SSH_KEY;
• whether the public key exists in authorized_keys;
• the SSH username;
• permissions on the ~/.ssh directory;
• the SSH port.

Permission denied when using Docker

For example:

Make sure the deployment user belongs to the:

group.

Check with:

After adding a user to the group, start a new login session before testing Docker again.

pull access denied

An error such as:

usually means:

• the image name is incorrect;
• the repository is private;
• the server is not authenticated with Docker Hub;
• registry credentials are incorrect.

The Container Exits Immediately

Check:

Then:

or:

The New Image Was Downloaded but the Website Does Not Work

Check:

• container logs;
• the application port;
• Nginx configuration;
• environment variables;
• database connectivity;
• firewall rules;
• the health endpoint.

How CI/CD Should Evolve as a Project Grows

You do not need to build a complex DevOps platform from day one.

You can start with a simple pipeline:

The key is to automate a process that is already repeatable and understood.

The complexity of the pipeline should grow together with the complexity of the project.

Conclusion

CI/CD turns deployment from a sequence of manual operations into a repeatable automated process.

In the architecture we built, a developer only needs to change the code and push it to GitHub.

GitHub Actions then:

1. retrieves the code;
2. installs dependencies;
3. runs tests;
4. builds a Docker image;
5. tags it with the current commit SHA;
6. pushes the image to Docker Hub;
7. connects to the production server;
8. downloads the new version;
9. updates the container through Docker Compose.

The complete path looks like this:

Even this relatively simple pipeline already provides several advantages:

• a consistent deployment process for every release;
• automatic code validation;
• fewer manual operations;
• deployment history;
• a direct link between the production version and a Git commit;
• fast rollback to a previous release;
• a foundation for staging, Kubernetes, and more advanced DevOps infrastructure.

Launch Your CI/CD Production Environment with Serverspace

A CI/CD pipeline needs an always-available server where the production version of the application can run.

With Serverspace, you can deploy an Ubuntu cloud VPS and configure Docker, Nginx, databases, and the other components of your production stack.

You can start with a single server:

As the project grows, you can split the infrastructure:

The same CI/CD model can therefore support both a small application and a more advanced multi-server infrastructure.

Deploy a VPS with Serverspace and build an automated path from a Git commit to a running application in production.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry