When an application works on my local machine, I often feel that the hardest part is over.
But getting it onto a VPS and sending someone a working HTTPS link still involves several tasks: cloning the repository, creating the environment file, choosing a build method, running the container, configuring a reverse proxy, pointing a domain, and issuing a TLS certificate.
None of these tasks is particularly new. The problem is that they repeat for almost every project.
That is why I built the deploy from Git repository feature in Nitrobase. The product has only recently launched and is still in Beta, so the goal of this feature is deliberately focused: shorten the path from source code to an application that can be reached on your own VPS.
One deployment begins with many small decisions
Suppose I have a repository containing a web application. Before I can run it on a server, I need to answer several questions:
- Which branch should be deployed?
- Does the application use a Dockerfile, or should its technology be detected automatically?
- Which port does the container listen on?
- Which environment variables are required?
- Which service should receive traffic for the domain?
- How should a new commit trigger another deployment?
For a single project, I can document the process in a README or shell script. As the number of applications grows, however, every project develops its own variation. An old script no longer fits exactly, the proxy configuration lives somewhere else, and sometimes only the person who created the system knows how to update it.
Nitrobase is not trying to replace Git or Docker. It aims to bring the separate tasks around them into one visible, repeatable process.
Three build methods for three common situations
Repositories are not all prepared in the same way. Nitrobase Beta therefore supports three primary build methods.
Dockerfile
If a repository already contains a Dockerfile, I want to keep using that definition.
A Dockerfile gives the project explicit control over its base image, dependencies, build steps, and startup command. In Nitrobase, the user can select the Dockerfile path, build target, and required build arguments.
This option fits applications that already have a stable container build or require a specialized build environment.
Railpack
Not every project needs a hand-written Dockerfile.
Railpack can analyze a repository and produce a build plan based on the technology it recognizes. This approach is useful for common application stacks when I want to focus on the source code instead of maintaining another build file.
The goal is not to hide the build process completely. Nitrobase still needs to expose the plan and logs so that, when something fails, the user can see where the process stopped.
Static site
A static website has simpler requirements: run a build command, collect the output directory, and serve the generated files.
Treating this as a separate option means users do not need to create a Dockerfile only to deploy documentation or a static frontend to a VPS.
These three methods are not intended to cover every possible repository. They address three common starting points: a project with a Dockerfile, a project that benefits from automatic build detection, and a website that only needs to serve static content.
A successful deployment still needs a public address
A running container does not necessarily mean that the application is ready for users.
When configuring everything manually, I still need to connect the container to a reverse proxy, create a route, prepare DNS, and obtain a certificate. This part often takes more time than it seems to deserve, especially when I only want to test a build on a VPS.
Nitrobase aims to connect the deployment step with endpoint creation. A new application can receive an sslip.io domain for testing without requiring a custom domain first. For production, the user can add a custom domain and use a Let's Encrypt certificate.
The problem this feature addresses is not only HTTPS. It closes the gap between two states:
“My container is running” and “A user can open my application through a URL.”
That gap looks small on an architecture diagram, but it often contains a surprising amount of manual configuration.
Pushing new code should not restart the process from scratch
After the first deployment, the next question is always: what happens when the repository receives a new commit?
The simplest approach is to SSH into the server, pull the code, and run the same sequence of commands again. It works, but it depends on memory and can introduce differences between releases.
Applications created from Git in Nitrobase have their own push webhook. Once the webhook is added to the repository, a push to the selected branch can trigger another build and deployment.
The webhook is verified with a secret instead of trusting every request sent to the endpoint. The aim is to make redeployment a controlled response to a repository change while keeping logs available when a build fails.
Because Nitrobase is still in Beta, this part particularly needs feedback from real repositories. Every build ecosystem has its own edge cases, and clear logs matter just as much as automation.
Environment variables should not live in the repository
Moving an application from Git to a server raises another familiar problem: source code can be version-controlled, but secrets should not be stored with it.
Database URLs, API keys, and signing secrets usually differ between local and production environments. They need to be entered separately, changed in a controlled way, and kept out of places where their raw values are unnecessary.
Nitrobase provides per-application environment configuration and masks secret values in the interface. This does not remove the responsibility of managing credentials, but it separates runtime configuration from the repository instead of encouraging users to commit a .env file.
To me, this is an essential part of deploying from Git. Cloning and building the code is only the first half. Supplying the correct configuration for the runtime environment is what determines whether the application actually works.
What problem is this feature trying to solve?
Deploying from Git is not a new idea. Many platforms already provide an excellent experience around it.
What Nitrobase is exploring is how to bring that experience to infrastructure the user owns. The VPS, containers, and data remain in the user's environment; Nitrobase handles the steps that connect the source code to the build, runtime, and HTTPS endpoint.
The workflow I want to reach can be summarized in five steps:
- choose a repository and branch;
- select Dockerfile, Railpack, or static site;
- enter the environment variables;
- deploy and receive an HTTPS URL;
- configure a webhook so future pushes can redeploy the application.
Git, Docker, the reverse proxy, and TLS still exist behind these steps. Nitrobase does not make them disappear. Its goal is to keep users from rebuilding the entire connection between them for every project.
One feature in a product that is still early
Nitrobase has only recently entered Beta, so deploying from Git still needs to be tested against more frameworks and repository structures.
I do not expect it to guess every project correctly. The first thing I want it to do well is provide a clear path: users should know which commit Nitrobase is cloning, which build method it selected, what configuration is required, and where an error occurred.
If you have a small application in a Git repository and an empty VPS, this is the distance the feature is trying to shorten.
Nitrobase source code: https://github.com/AydenGroup/nitrobase
Top comments (0)