Harness Open Source
Overview
Harness Open Source, formerly Gitness and built by the team behind Drone, is an all-in-one, self-hosted software delivery platform. It brings together Git repository hosting, pull requests and code review, CI and CD pipelines, and a built-in artifact registry in a single web application backed by an embedded database. A team can host code and ship it without stitching together several separate services.
This SecureAnyCloud image installs Docker CE from the official Docker repository and runs the official Harness image as a container, pinned by its @sha256 digest. Docker manages the container with a restart policy. Harness makes the first account that registers an administrator, so the image seeds the admin with a unique password generated on the first boot of every VM and switches off open self-registration. No default credential works, and no attacker can register the first account and seize the server.
What you get:
- Harness Open Source running as a container managed by Docker, with the official image pinned by
@sha256digest - Docker CE preinstalled from the official Docker apt repository, with the socket mounted so that pipeline steps run as containers on the instance
- The Harness web UI and Git over HTTP on
:80, served on the loopback connector 127.0.0.1:3000 behind an nginx reverse proxy, and Git over SSH on:3022through the built-in Harness SSH server - An embedded SQLite database, so there is no separate database server to run
- A unique administrator password generated on first boot and recorded in a root-only file
- Open self-registration switched off, so no second account can be created from the sign-in page
- A database created fresh per instance, with no baked users, tokens or secrets
docker.serviceandnginx.serviceas systemd units, enabled and active- An unauthenticated
/healthzendpoint for Azure Load Balancer health probes - 24/7 SecureAnyCloud support
Prerequisites
You need an active Azure subscription, an SSH key pair, and a VNet and subnet in the target region.
Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point for core Git hosting, the web UI and the registry. For the NSG, allow these inbound ports:
22/tcpfrom your management network80/tcpfor the web UI and Git over HTTP3022/tcpfor Git over SSH
Harness serves plain HTTP on port 80. For production, terminate TLS in front of it with your own domain and consider adding 443/tcp (see Maintenance).
Step 1 - Deploy from the Azure Marketplace
Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Harness Open Source by SecureAnyCloud, and select Create.
On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80). Then select Review + create and Create.
After deployment, open ports 80, 3022 (and optionally 443) on the network security group.
Step 2 - Deploy from the Azure CLI
Accept the Marketplace terms once per subscription, then create the VM and open the ports:
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:harness-open-source:default:latest
az vm create \
--resource-group <your-rg> \
--name harness \
--image sac1647283583153:harness-open-source:default:latest \
--size Standard_B2s \
--admin-username azureuser \
--ssh-key-values ~/.ssh/id_ed25519.pub \
--vnet-name <your-vnet> --subnet <your-subnet> \
--public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name harness --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name harness --port 3022 --priority 1020Step 3 - Connect to your VM
Connect over SSH as azureuser:
ssh azureuser@<vm-public-ip>Step 4 - Confirm the services are running
Check the two systemd units and the container:
systemctl is-active docker.service nginx.service
sudo docker ps --filter name=harness --format 'table {{.Names}}\t{{.Status}}'Both systemd units report active, and Docker shows the harness container Up.
Docker manages the Harness service. The web UI and Git over HTTP are bound to the loopback connector 127.0.0.1:3000, Git over SSH is on 3022, and nginx fronts the service on port 80. The container mounts the host Docker socket, so CI and CD pipeline steps run as containers.
Step 5 - Retrieve your administrator credentials
Harness makes the first account that registers an administrator, so this image pre-seeds that admin with a unique password. The password is generated on the first boot of your VM and written to a root-only file. Read the file:
sudo cat /root/harness-credentials.txtThe file contains HARNESS_URL, HARNESS_USERNAME (which is admin) and HARNESS_PASSWORD. Store the password somewhere safe.
The official Harness image is pinned by its @sha256 digest, so every instance runs the exact same verified build.
Step 6 - Confirm there is no default credential and no open sign-up
nginx serves an unauthenticated health endpoint for load balancers:
curl -s http://localhost/healthzIt returns ok.
Now confirm the security posture. The admin signs in with the per-instance password, the well-known admin / admin default is rejected, and public self-registration is disabled:
curl -s -o /dev/null -w 'admin + per-VM password: %{http_code}\n' -X POST 'http://127.0.0.1/api/v1/login?include_cookie=false' -H 'Content-Type: application/json' -d '{"login_identifier":"admin","password":"<HARNESS_PASSWORD>"}'
curl -s -o /dev/null -w 'admin / admin (default): %{http_code}\n' -X POST 'http://127.0.0.1/api/v1/login?include_cookie=false' -H 'Content-Type: application/json' -d '{"login_identifier":"admin","password":"admin"}'
curl -s -o /dev/null -w 'public self-registration: %{http_code}\n' -X POST 'http://127.0.0.1/api/v1/register?include_cookie=false' -H 'Content-Type: application/json' -d '{"uid":"attacker","email":"a@b.c","display_name":"a","password":"Sup3rSecret1"}'The per-instance password returns 200 (authenticated). The default admin / admin returns 404, because Harness deliberately hides whether the user exists on a bad password. The public register endpoint returns 403 with User sign-up is disabled.
So no default or blank credential works, and no one can register the first account and seize the server.
Step 7 - Sign in to the web UI
Browse to http://<vm-public-ip>/. Harness shows its sign-in page.
Enter the user id admin and the password from Step 5, then select Sign In. Open self-registration is disabled, so the sign-in page is the only way in, and only your seeded admin can authenticate.
Step 8 - Browse your repositories
After signing in, select a project. Harness groups repositories, pipelines and secrets into projects, which are also called spaces.
Inside a project, the Repositories page lists every repository with its description and last update. The left rail also shows the Artifact Registries, Gitspaces, Secrets, Members and Settings sections.
Step 9 - Create a repository
Choose New Repository. Give it a name and an optional description, and pick a default branch. Optionally add a licence, a .gitignore and a README, then select Create Repository.
Your new repository is ready to clone and push to immediately.
Step 10 - Push code over HTTPS or SSH
Each repository exposes a clone URL over HTTP (through nginx on port 80) and over the Harness SSH server (port 3022). Clone, commit and push as usual. Authenticate with your admin credentials or with a personal access token that you create under your profile:
# Over HTTPS (through nginx on port 80)
git clone http://<vm-public-ip>/git/<space>/<repo>.git
# Over SSH (the Harness built-in SSH server on port 3022; add your SSH key to your Harness profile first)
git clone ssh://git@<vm-public-ip>:3022/<space>/<repo>.git cd <repo>
git add .
git commit -m "First commit"
git push origin mainStep 11 - Open a pull request
Push a feature branch, then open a pull request to propose merging it into your default branch.
The pull request view shows the commits and changes, whether the branch merges cleanly, review requirements, and a conversation timeline. When the pull request is ready, use the Squash and merge action.
Step 12 - Run CI and CD pipelines
Harness runs pipeline steps as Docker containers on this instance through the host Docker socket, which the Harness container has mounted. Confirm the mount:
sudo docker inspect harness --format '{{range .Mounts}}{{.Source}} -> {{.Destination}};{{end}}' | tr ';' '\n' | grep docker.sockThe output shows /var/run/docker.sock -> /var/run/docker.sock.
Define a pipeline in a repository (Harness stores pipeline definitions as code). Its steps execute in containers on this VM, so you get CI and CD next to your Git hosting with nothing else to install.
Maintenance
- Admin password: the administrator password is generated on first boot and stored in
/root/harness-credentials.txt. To change it, sign in and use the web UI (your profile, then Password). A password you set in the UI persists across reboots. - Data: all repositories, pull requests, pipeline definitions, registry blobs and the embedded SQLite database live under
/var/lib/harnesson the instance disk. Back up that path to preserve your data. - Upgrades: Harness runs as the
harnesscontainer from the official image pinned by digest. To upgrade an already running VM, pull the new tag withsudo docker pull harness/harness:<new-tag>. Then recreate the container with the same-v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/harness:/databinding and the environment file at/etc/sac/harness.env. - TLS: Harness serves plain HTTP on port 80. Front it with TLS (for example, certbot with your own domain) before you run it in production.
- Security patches: unattended-upgrades remains enabled, so the OS continues to receive security updates automatically.
- License: Harness Open Source is Apache 2.0 licensed. This image ships the open-source project, and the SecureAnyCloud charge covers packaging, security patching, image maintenance and support.
Support
SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.
Deploy on Azure
Launch Harness Open Source on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.
View this image
Need Help?
Our support team is available 24/7.
sales@secureanycloud.com
Overview
Harness Open Source, formerly Gitness and built by the team behind Drone, is an all-in-one, self-hosted software delivery platform. It brings together Git repository hosting, pull requests and code review, CI and CD pipelines, and a built-in artifact registry in a single web application backed by an embedded database. A team can host code and ship it without stitching together several separate services.
This SecureAnyCloud image installs Docker CE from the official Docker repository and runs the official Harness image as a container, pinned by its @sha256 digest. Docker manages the container with a restart policy. Harness makes the first account that registers an administrator, so the image seeds the admin with a unique password generated on the first boot of every instance and switches off open self-registration. No default credential works, and no attacker can register the first account and seize the server.
What you get:
- Harness Open Source running as a container managed by Docker, with the official image pinned by
@sha256digest - Docker CE preinstalled from the official Docker apt repository, with the socket mounted so that pipeline steps run as containers on the instance
- The Harness web UI and Git over HTTP on
:80, served on the loopback connector 127.0.0.1:3000 behind an nginx reverse proxy, and Git over SSH on:3022through the built-in Harness SSH server - An embedded SQLite database, so there is no separate database server to run
- A unique administrator password generated on first boot and recorded in a root-only file
- Open self-registration switched off, so no second account can be created from the sign-in page
- A database created fresh per instance, with no baked users, tokens or secrets
- A dedicated EBS data volume mounted at
/var/lib/harness, holding the database, repositories and registry blobs. All persistent data lives on this volume docker.serviceandnginx.serviceas systemd units, enabled and active- An unauthenticated
/healthzendpoint for load balancer health checks - 24/7 SecureAnyCloud support
Prerequisites
You need an AWS account, an EC2 key pair in the target region, and a VPC with a public subnet.
m5.large (2 vCPU / 8 GiB RAM) is the recommended instance type for core Git hosting, the web UI, the registry and pipeline execution. For the security group, allow these inbound ports:
22/tcpfrom your management network for SSH80/tcpfor the web UI and Git over HTTP3022/tcpfor Git over SSH
Harness serves plain HTTP on port 80. For production, terminate TLS in front of it with your own domain and consider adding 443/tcp (see Maintenance).
Step 1 - Launch the AMI from the console
In the EC2 console, choose Launch instance. Under Application and OS Images, select My AMIs (or AWS Marketplace AMIs) and pick the SecureAnyCloud Harness Open Source image.
Choose an m5.large instance type, select your key pair, and configure the security group to allow 22/tcp, 80/tcp and 3022/tcp as described in the prerequisites. Leave the default root volume, because the image already declares a dedicated data volume for /var/lib/harness. Launch the instance and wait for the status checks to pass.
Step 2 - Launch from the AWS CLI
Launch the instance with the AWS CLI. Replace the values in angle brackets:
aws ec2 run-instances \
--image-id <harness-open-source-ami-id> \
--instance-type m5.large \
--key-name <your-key-pair> \
--security-group-ids <sg-with-22-80-3022> \
--subnet-id <your-public-subnet> \
--associate-public-ip-address \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=harness}]'Step 3 - Connect to your instance
Connect over SSH using your key pair and the login user for the OS variant you launched. For Ubuntu 24.04, the SSH login user is ubuntu, and the connect command is ssh -i <your-key.pem> ubuntu@<instance-public-ip>.
Step 4 - Confirm the services are running
Check the two systemd units and the container:
systemctl is-active docker.service nginx.service docker ps --filter name=harness --format 'table {{.Names}}\t{{.Status}}'Both systemd units report active, and Docker shows the harness container Up.
Docker manages the Harness service. The web UI and Git over HTTP are bound to the loopback connector 127.0.0.1:3000, Git over SSH is on 3022, and nginx fronts the service on port 80. The container mounts the host Docker socket, so CI and CD pipeline steps run as containers.
Step 5 - Retrieve your administrator credentials
Harness makes the first account that registers an administrator, so this image pre-seeds that admin with a unique password. The password is generated on the first boot of your instance and written to a root-only file. Read the file:
sudo cat /root/harness-credentials.txtThe file contains HARNESS_URL, HARNESS_USERNAME (which is admin) and HARNESS_PASSWORD. Store the password somewhere safe.
The official Harness image is pinned by its @sha256 digest, so every instance runs the exact same verified build.
Step 6 - Confirm there is no default credential and no open sign-up
nginx serves an unauthenticated health endpoint for load balancers:
curl -s http://localhost/healthzIt returns ok.
Now confirm the security posture. The admin signs in with the per-instance password, the well-known admin / admin default is rejected, and public self-registration is disabled:
curl -s -o /dev/null -w 'admin + per-VM password: %{http_code}\n' -X POST 'http://127.0.0.1/api/v1/login?include_cookie=false' -H 'Content-Type: application/json' -d '{"login_identifier":"admin","password":"<HARNESS_PASSWORD>"}'
curl -s -o /dev/null -w 'admin / admin (default): %{http_code}\n' -X POST 'http://127.0.0.1/api/v1/login?include_cookie=false' -H 'Content-Type: application/json' -d '{"login_identifier":"admin","password":"admin"}'
curl -s -o /dev/null -w 'public self-registration: %{http_code}\n' -X POST 'http://127.0.0.1/api/v1/register?include_cookie=false' -H 'Content-Type: application/json' -d '{"uid":"attacker","email":"a@b.c","display_name":"a","password":"Sup3rSecret1"}'The per-instance password returns 200 (authenticated). The default admin / admin returns 404, because Harness deliberately hides whether the user exists on a bad password. The public register endpoint returns 403 with User sign-up is disabled.
So no default or blank credential works, and no one can register the first account and seize the server.
Step 7 - Sign in to the web UI
Browse to http://<instance-public-ip>/. Harness shows its sign-in page.
Enter the user id admin and the password from Step 5, then select Sign In. Open self-registration is disabled, so the sign-in page is the only way in, and only your seeded admin can authenticate.
Step 8 - Browse your repositories
After signing in, select a project. Harness groups repositories, pipelines and secrets into projects, which are also called spaces.
Inside a project, the Repositories page lists every repository with its description and last update. The left rail also shows the Artifact Registries, Gitspaces, Secrets, Members and Settings sections.
Choose New Repository to create a repository. Give it a name, an optional description and a default branch, and optionally add a licence, a .gitignore and a README.
Step 9 - Browse code and push over HTTP or SSH
Open a repository to browse its files, commits, branches and tags. The README is rendered, and a summary shows the commit, branch, tag and open pull request counts.
Each repository exposes a clone URL over HTTP (through nginx on port 80) and over the Harness SSH server (port 3022). Clone, commit and push as usual. Authenticate with your admin credentials or with a personal access token that you create under your profile.
# Over HTTP (through nginx on port 80)
git clone http://<instance-public-ip>/git/<space>/<repo>.git
# Over SSH (the Harness built-in SSH server on port 3022; add your SSH key to your Harness profile first)
git clone ssh://git@<instance-public-ip>:3022/<space>/<repo>.git cd <repo>
git add .
git commit -m "First commit"
git push origin mainStep 10 - Open a pull request
Push a feature branch, then open a pull request to propose merging it into your default branch.
The pull request view shows the commits and changes, whether the branch merges cleanly, review requirements, and a conversation timeline. When the pull request is ready, use the Squash and merge action.
Step 11 - Run CI and CD pipelines
Harness runs pipeline steps as Docker containers on this instance through the host Docker socket, which the Harness container has mounted. Confirm the mount:
docker inspect harness --format '{{range .Mounts}}{{.Source}} -> {{.Destination}};{{end}}' | tr ';' '\n' | grep docker.sockThe output shows /var/run/docker.sock -> /var/run/docker.sock.
Define a pipeline in a repository (Harness stores pipeline definitions as code under .harness/). Its steps execute in containers on this instance, so you get CI and CD next to your Git hosting with nothing else to install. Each execution shows every stage with live logs and per-step timing.
Maintenance
- Admin password: the administrator password is generated on first boot and stored in
/root/harness-credentials.txt. To change it, sign in and use the web UI (your profile, then Password). A password you set in the UI persists across reboots. - Data: all repositories, pull requests, pipeline definitions, registry blobs and the embedded SQLite database live under
/var/lib/harnesson a dedicated EBS data volume. Snapshot or back up that volume to preserve your data. You can grow it independently of the OS disk as your repositories and registry grow. - Upgrades: Harness runs as the
harnesscontainer from the official image pinned by digest. To upgrade an already running instance, pull the new tag withsudo docker pull harness/harness:<new-tag>. Then recreate the container with the same-v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/harness:/databinding and the environment file at/etc/sac/harness.env. - TLS: Harness serves plain HTTP on port 80. Front it with TLS (for example, certbot with your own domain) before you run it in production, and open
443/tcpon the security group. - Security patches: unattended-upgrades remains enabled, so the OS continues to receive security updates automatically.
- License: Harness Open Source is Apache 2.0 licensed. This image ships the open-source project, and the SecureAnyCloud charge covers packaging, security patching, image maintenance and support.
Support
SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.
Deploy on AWS
Launch Harness Open Source with 24/7 support from SecureAnyCloud.
View on Marketplace
Need Help?
Our support team is available 24/7.
sales@secureanycloud.com