C
Deploying a Node app usually comes down to two options, and neither one is great.
You can spin up a plain VPS, install Node by hand, wire up NGINX as a reverse proxy, configure PM2 to keep the process alive, and set up SSL yourself. Or you can push everything to a serverless platform and accept cold starts, a pricing model that gets unpredictable the moment traffic spikes, and a runtime that doesn't want to hold a persistent connection open for long.
Neither is a great fit for a small app that just needs to run reliably without turning into a part time ops job.
Cloudways Velocity is built around a third option, where you connect a GitHub repository directly to Velocity and let it handle the build, the process, and the deploy on every push. Velocity just reached general availability, and to show what that actually looks like in practice, we walked a small demo app through the full deployment lifecycle that covers the first deploy, auto deploy on push, environment variables, and rollback.
Deploying from a repository means your Git history becomes the actual source of truth for what's running in production. Instead of manually copying files to a server or writing your own build script, you connect a repository and a branch, and the platform figures out how to build and start the app on its own. Every commit you push becomes a candidate for what goes live next, and every past commit is something you can go back to if a new one breaks something.
That sounds simple, and it mostly is. But the value only becomes obvious once you've felt the alternative, so before getting into the demo it's worth being specific about why this fits a certain category of app better than serverless does.
A few things become clear once you run even a small app on a persistent process instead of a serverless function.
There are no cold starts. The process stays running, so the first request after a quiet stretch isn't paying a startup tax.
Pricing stays flat. You aren't billed per invocation or per execution duration, so a sudden spike in traffic doesn't turn into a surprise on the invoice.
Long lived connections behave the way you'd expect. Things like WebSockets or long polling sit naturally on a persistent process, but they fight against the execution time limits serverless platforms impose.
Background work can just run. A cron style job or a queue worker can live inside the same process instead of needing its own separate function and its own deployment pipeline.
None of this makes serverless a bad choice in general. If your workload is genuinely spiky, mostly idle with occasional bursts, or you want to think about infrastructure as little as possible, serverless still makes sense. The tradeoff only tips toward something like Velocity once your app runs consistently enough that paying for an always on process is the more predictable, and often cheaper, option.
This approach fits a specific range of projects that include an internal tool a small team relies on daily, an MVP you're trying to get in front of users without spending a week on infrastructure, a small backend that's outgrown a serverless free tier, or a side project you want to keep alive without babysitting a server.
As such, Velocity is not the platform to go with if you need deep control over the underlying infrastructure or custom networking, or you're operating at a scale where flat pricing stops being an advantage.
To show this in practice, we built a single page Express app we're calling deploy status dashboard. It shows an app name and a version badge, a build info panel that reads real values off the running process (the Node version, the environment, an environment variable set later, and the time the server started), a row of feature cards, and a theme color applied across the page.
Keeping it this simple was intentional. As we pushed a new version, added an environment variable, and rolled back a deploy, we wanted to be able to tell what happened just by looking at a screenshot instead of digging through logs. The rest of the app is a single Express route that renders this data into a page with a dark background.
We pushed this to a GitHub repository named deploy-status-dashboard, matching the name already set in package.json, so there was no mismatch between what the code called itself and what the repo was called.
Getting the code onto GitHub was the ordinary Git workflow.
From there, connecting it to Velocity took a few clicks. In the Cloudways console, we created a new Velocity application, connected our GitHub account, and picked the deploy-status-dashboard repository along with the main branch.
This is normally where a whole section of manual configuration would live on a bare VPS. Velocity read package.json and detected on its own that this was an Express app, along with which Node version to run it on. There was no build command or start command to write, and nothing to get wrong.
After confirming the detected configuration, we deployed and waited for the build to finish. Opening the live URL showed the blue theme, the v1.0.0 badge, the single Core Deploy card, and a build info panel populated with real values pulled straight from the running process.
This is the section that best demonstrates the whole approach. We made three small changes to the code: bumped the version to v2.0.0, changed the theme color from blue to orange, and added a second feature card labeled Auto Deploy Enabled. Here is the code diff:
Then we committed and pushed, the same way you would for any other change. We didn't touch the Velocity dashboard after that. Within a couple of minutes, a new deployment appeared in the Deployments tab on its own. Reloading the live URL showed the orange theme, the v2.0.0 badge, and the new card.
Here is how the Deployments tab looked after the second deployment:
That's the entire pipeline for a very common edit, commit, and push sequence in app deployment. There were no SSH sessions or manual restarts involved.
Next, we wanted to show how Velocity handles configuration that shouldn't live in the code itself. The path is App Settings >> Environment Variables >> Add Variable. We set APP_ENV_LABEL to PRODUCTION, the exact variable name the app was already reading through process.env.APP_ENV_LABEL || 'Not Set', so no code change was required for this part. Saving with the redeploy option triggered a fresh build so the new value would actually take effect.
After the redeploy finished, reloading the live URL showed the Env Label row in the build info panel updated from Not Set to PRODUCTION.
The last thing we wanted to test was rollback, since deployment history is only useful if going backward is as easy as going forward. In the Deployments tab, we found the v1 deployment and rolled back to it.
The live app reverted almost immediately, with the blue theme, v1.0.0 badge, and the single Core Deploy card again. For anyone shipping to production without a large team behind them, that feature alone can save hours of deployment and redeployment work.
One thing worth calling out is that the Env Label still showed PRODUCTION after the rollback, even though it had been set after the v1 deploy had already gone live. Environment variables in Velocity are scoped to the application itself, not to a specific deployment, so rolling back the code doesn't roll back the environment configuration. The theme and the feature cards reverted because those live in the code.
This is a useful detail to know because you can rest assured that your global environment variables are available regardless of redeployments and rollbacks.
Use code HACKERNOON5 for $5 in hosting credits if you want to try this yourself.
This walkthrough is close to the actual workflow Velocity is built around. We showed the push code, got a deploy, and rolled back cleanly when something needed to go back a step. It won't be the right fit for every project. If you need deep custom infrastructure control, or your app needs configuration outside what a framework preset expects, you'll hit the edges of this approach fairly quickly. But for an internal tool, an MVP, or a small backend that's outgrown a free serverless tier, deploying straight from a repo removes a surprising amount of the operational overhead that usually comes with hosting a Node app.
You can spin up a plain VPS, install Node by hand, wire up NGINX as a reverse proxy, configure PM2 to keep the process alive, and set up SSL yourself. Or you can push everything to a serverless platform and accept cold starts, a pricing model that gets unpredictable the moment traffic spikes, and a runtime that doesn't want to hold a persistent connection open for long.
Neither is a great fit for a small app that just needs to run reliably without turning into a part time ops job.
Cloudways Velocity is built around a third option, where you connect a GitHub repository directly to Velocity and let it handle the build, the process, and the deploy on every push. Velocity just reached general availability, and to show what that actually looks like in practice, we walked a small demo app through the full deployment lifecycle that covers the first deploy, auto deploy on push, environment variables, and rollback.
What "Deploying From a Repo" Actually Means
Deploying from a repository means your Git history becomes the actual source of truth for what's running in production. Instead of manually copying files to a server or writing your own build script, you connect a repository and a branch, and the platform figures out how to build and start the app on its own. Every commit you push becomes a candidate for what goes live next, and every past commit is something you can go back to if a new one breaks something.
That sounds simple, and it mostly is. But the value only becomes obvious once you've felt the alternative, so before getting into the demo it's worth being specific about why this fits a certain category of app better than serverless does.
Why Velocity Beats Serverless for Simple to Moderate Workloads
A few things become clear once you run even a small app on a persistent process instead of a serverless function.
There are no cold starts. The process stays running, so the first request after a quiet stretch isn't paying a startup tax.
Pricing stays flat. You aren't billed per invocation or per execution duration, so a sudden spike in traffic doesn't turn into a surprise on the invoice.
Long lived connections behave the way you'd expect. Things like WebSockets or long polling sit naturally on a persistent process, but they fight against the execution time limits serverless platforms impose.
Background work can just run. A cron style job or a queue worker can live inside the same process instead of needing its own separate function and its own deployment pipeline.
None of this makes serverless a bad choice in general. If your workload is genuinely spiky, mostly idle with occasional bursts, or you want to think about infrastructure as little as possible, serverless still makes sense. The tradeoff only tips toward something like Velocity once your app runs consistently enough that paying for an always on process is the more predictable, and often cheaper, option.
Who This Is For
This approach fits a specific range of projects that include an internal tool a small team relies on daily, an MVP you're trying to get in front of users without spending a week on infrastructure, a small backend that's outgrown a serverless free tier, or a side project you want to keep alive without babysitting a server.
As such, Velocity is not the platform to go with if you need deep control over the underlying infrastructure or custom networking, or you're operating at a scale where flat pricing stops being an advantage.
Building the Demo App
To show this in practice, we built a single page Express app we're calling deploy status dashboard. It shows an app name and a version badge, a build info panel that reads real values off the running process (the Node version, the environment, an environment variable set later, and the time the server started), a row of feature cards, and a theme color applied across the page.
Keeping it this simple was intentional. As we pushed a new version, added an environment variable, and rolled back a deploy, we wanted to be able to tell what happened just by looking at a screenshot instead of digging through logs. The rest of the app is a single Express route that renders this data into a page with a dark background.
We pushed this to a GitHub repository named deploy-status-dashboard, matching the name already set in package.json, so there was no mismatch between what the code called itself and what the repo was called.
Pushing to GitHub and Connecting Velocity
Getting the code onto GitHub was the ordinary Git workflow.
Code:
git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/zfrqbl-CW/deploy-status-dashboard
git branch -M main
git push -u origin mainFrom there, connecting it to Velocity took a few clicks. In the Cloudways console, we created a new Velocity application, connected our GitHub account, and picked the deploy-status-dashboard repository along with the main branch.
Framework Detection
This is normally where a whole section of manual configuration would live on a bare VPS. Velocity read package.json and detected on its own that this was an Express app, along with which Node version to run it on. There was no build command or start command to write, and nothing to get wrong.
The First Deploy
After confirming the detected configuration, we deployed and waited for the build to finish. Opening the live URL showed the blue theme, the v1.0.0 badge, the single Core Deploy card, and a build info panel populated with real values pulled straight from the running process.
Auto Deploy on Push
This is the section that best demonstrates the whole approach. We made three small changes to the code: bumped the version to v2.0.0, changed the theme color from blue to orange, and added a second feature card labeled Auto Deploy Enabled. Here is the code diff:
Code:
- const APP_VERSION = 'v1.0.0';
- const THEME_COLOR = '#2563eb'; // blue
+ const APP_VERSION = 'v2.0.0';
+ const THEME_COLOR = '#f97316'; // orange
const FEATURES = [
{
title: 'Core Deploy',
description: 'Base application deployed straight from the connected Git repository.',
},
+ {
+ title: 'Auto Deploy Enabled',
+ description: 'This build shipped automatically after a git push, no manual redeploy step needed.',
+ },
];Then we committed and pushed, the same way you would for any other change. We didn't touch the Velocity dashboard after that. Within a couple of minutes, a new deployment appeared in the Deployments tab on its own. Reloading the live URL showed the orange theme, the v2.0.0 badge, and the new card.
Here is how the Deployments tab looked after the second deployment:
That's the entire pipeline for a very common edit, commit, and push sequence in app deployment. There were no SSH sessions or manual restarts involved.
Environment Variables
Next, we wanted to show how Velocity handles configuration that shouldn't live in the code itself. The path is App Settings >> Environment Variables >> Add Variable. We set APP_ENV_LABEL to PRODUCTION, the exact variable name the app was already reading through process.env.APP_ENV_LABEL || 'Not Set', so no code change was required for this part. Saving with the redeploy option triggered a fresh build so the new value would actually take effect.
After the redeploy finished, reloading the live URL showed the Env Label row in the build info panel updated from Not Set to PRODUCTION.
Deployment History and Rollback
The last thing we wanted to test was rollback, since deployment history is only useful if going backward is as easy as going forward. In the Deployments tab, we found the v1 deployment and rolled back to it.
The live app reverted almost immediately, with the blue theme, v1.0.0 badge, and the single Core Deploy card again. For anyone shipping to production without a large team behind them, that feature alone can save hours of deployment and redeployment work.
One thing worth calling out is that the Env Label still showed PRODUCTION after the rollback, even though it had been set after the v1 deploy had already gone live. Environment variables in Velocity are scoped to the application itself, not to a specific deployment, so rolling back the code doesn't roll back the environment configuration. The theme and the feature cards reverted because those live in the code.
This is a useful detail to know because you can rest assured that your global environment variables are available regardless of redeployments and rollbacks.
Use code HACKERNOON5 for $5 in hosting credits if you want to try this yourself.
Closing Thoughts
This walkthrough is close to the actual workflow Velocity is built around. We showed the push code, got a deploy, and rolled back cleanly when something needed to go back a step. It won't be the right fit for every project. If you need deep custom infrastructure control, or your app needs configuration outside what a framework preset expects, you'll hit the edges of this approach fairly quickly. But for an internal tool, an MVP, or a small backend that's outgrown a free serverless tier, deploying straight from a repo removes a surprising amount of the operational overhead that usually comes with hosting a Node app.