My team was drowning in CI maintenance. We had spent the better part of two years nursing a sprawling Jenkins instance that seemed to break every time a plugin updated, followed by a brief and frustrating stint with GitLab runners that constantly idled or ran out of credits at the worst possible times. I was spending more time writing Groovy pipelines and debugging infrastructure than actually reviewing code. I needed a CI system that wouldn't make me manage the build servers myself.
That's what led me to Harness Continuous Integration. I had heard about their hosted build infrastructure—Harness Cloud—and the promise of not having to manage VMs or containers was enough to get me to sign up for a trial. Here's how I got my first build running, the mistakes I made along the way, and what I learned.
Setting Up the Pipeline
After logging into my Harness account, the first thing you'll notice is the module selector in the top left corner. I navigated to the Continuous Integration module.
From there, creating the pipeline is straightforward:
- Click Pipelines in the left nav.
- Click + Create a Pipeline.
- Name it (I called mine
node-api-build) and click Start.
This opens the visual pipeline editor. Unlike Jenkinsfiles where you're staring at a wall of Groovy, Harness uses a visual canvas. I was skeptical of visual editors at first—they usually limit what you can do—but I decided to give it a fair shot.
Adding the Build Stage
With the pipeline created, I needed to add a stage. I clicked Add Stage, selected Build as the stage type, and named it build_and_test.
This is where you connect your code. Harness asks for your Git provider. If you're using GitHub, GitLab, Bitbucket, or their own Harness Code Repository, you'll need to set up a Connector.
My first mistake: I tried to rush through the connector setup. I selected GitHub, clicked "Create New Connector," and just pasted in my Personal Access Token without scoping the repository permissions correctly. The connection test failed silently—it said "Success" but couldn't find my repo when I tried to select it in the dropdown.
I had to go back, delete the connector, and create a new one. This time, I made sure my GitHub PAT had the repo scope checked, and I explicitly set the API URL to https://api.github.com (not the enterprise URL, which is the default in some templates). Once I did that, the connector test passed, and I could select my node-api repository from the dropdown. I clicked Set up Stage.
Choosing the Infrastructure
This was the part I was most interested in. Inside my new CI stage, I clicked the Infrastructure tab.
Harness gives you a few options here: you can run builds on your own local VMs, a Kubernetes cluster, or Harness Cloud. I selected Cloud.
Harness Cloud uses Harness-mananced infrastructure that spins up on-demand and spins down when your build finishes. I left the default options for the operating system (Linux) and architecture (amd64) and clicked Continue.
The whole infrastructure setup took about three clicks. Compared to the hours I've spent configuring GitLab runners or provisioning EC2 instances for Jenkins agents, this felt almost suspiciously easy.
Configuring the Execution Steps
Now for the actual work: telling the pipeline what to do. I clicked the Execution tab inside my stage.
Harness has a step library with pre-built steps for common actions—Docker builds, pushing images, running tests. But I wanted to start simple, so I clicked the plus button to add a step and selected Run from the step library. A Run step lets you execute arbitrary shell commands.
I named the step install_and_test. For the build command, I entered:
npm ci
npm run test
My second mistake: I didn't configure the shell type. The Run step defaults to executing commands in a shell, but I didn't realize that the default container image Harness uses might not have Node.js installed. When I ran the pipeline, it failed immediately with npm: command not found.
To fix this, I went back into the Run step settings and found the Container Registry and Image fields. I set the image to node:18-alpine. This tells Harness to run my commands inside a Node.js container.
I also noticed an Optional Configuration section in the Run step. I expanded it and found settings for resource limits. My tests were fairly lightweight, so I left the memory at the default (500Mi) but bumped the CPU limit slightly just in case.
Running the Build and Checking Results
I hit Save and then Run.
The pipeline kicked off, and I was taken to the execution view. This is where I could watch the build happen in real-time. Harness Cloud took about 15-20 seconds to provision the build infrastructure—significantly faster than the 2-3 minutes I was used to with cold-starting Jenkins agents.
The npm ci command downloaded dependencies, and npm run test executed my test suite. The whole pipeline completed in about 1 minute and 45 seconds.
The execution view shows a clear pass/fail for each step, and you can click into any step to see the full console output. It's clean, readable, and doesn't require you to dig through a wall of log text to find the one line that matters.
What I Wish I Knew Earlier
After getting the basic build working, I spent some time exploring features that would have made my initial setup even smoother:
Test Intelligence: This is Harness's standout feature. It analyzes your code changes and only runs the tests that are actually affected by those changes, rather than your entire test suite. On a large project, this can cut test execution time by up to 80%. I haven't set it up yet for my small project, but I can see how it would be transformative for a monorepo with thousands of tests.
Caching: I noticed my npm ci step was downloading dependencies from scratch on every run. Harness supports intelligent caching. You can configure a Cache step before your Run step to save and restore your node_modules directory (or Maven .m2, pip cache, etc.) between builds. Setting this up cut my build time from 1:45 down to about 45 seconds.
YAML Mode: While the visual editor is great for getting started, you can switch to YAML mode at any time by toggling the YAML/Visual slider in the top right of the pipeline editor. This is crucial for version-controlling your pipeline configuration alongside your code. I now make all my changes in YAML and commit them to the repo.
Honest Limitations
No tool is perfect, and Harness CI has its trade-offs:
The learning curve for Connectors: Setting up connectors for GitHub, Docker registries, and cloud providers involves navigating a lot of permission scopes and authentication methods. It's not harder than other CI tools, but it's not trivial either. Give yourself an hour just for connector setup on your first try.
Harness Cloud availability: While the on-demand infrastructure is fantastic, it's not available in every region yet. If you have strict data residency requirements, you may need to run builds on your own infrastructure, which brings back some of the management overhead you were trying to avoid.
Pricing complexity: Harness uses a credit-based system for builds on Harness Cloud. It's generous for a trial, but you'll want to model your expected build volume carefully before committing, especially if your team runs dozens of builds per day across multiple branches.
Less community content: Compared to Jenkins or GitHub Actions, there are far fewer community-written plugins or reusable pipeline snippets for Harness. The built-in step library covers most needs, but if you have a very niche tool in your build process, you might be writing custom Run steps rather than dropping in a pre-made action.
Final Thoughts
Getting a working CI pipeline in Harness took me about 30 minutes, including the time I spent debugging my connector and container image mistakes. The experience of not having to provision, maintain, or pay for idle build infrastructure is genuinely liberating.
If you're tired of nursing CI servers or watching your team's productivity drain into YAML debugging sessions, Harness CI is worth a serious look. Start with a simple Run step on Harness Cloud, get your tests passing, and then explore the caching and Test Intelligence features—that's where the real time savings kick in.