Deploy from GitHub

How GitHub deployments work

A GitHub deployment connects an application in ForgeVPS to a repository and branch. ForgeVPS gets the code, runs the configured install and build commands, and starts the application on your selected machine. Later pushes to that branch trigger another deployment.

This flow is available in hosted ForgeVPS. On self-hosted, use a Development server or Production server for a project already on the machine.

You can still use Git in Files or Terminal without creating a GitHub deployment. The deployment connection is specifically what turns pushes into application releases.

Choose a repository and branch

1. Open Servers → Add server and choose the GitHub repository option.
2. Connect a GitHub account if prompted, then select the repository you want to deploy.
3. Choose the branch. Pushes to another branch do not update this server.
4. Review the suggested install, build, and start commands. Adjust them to match the project’s instructions.
5. Finish connecting the repository and open the new entry under GitHub Deployments.

If the repository is missing, check that the GitHub connection has access to that repository and that you have selected the correct account.

Understand the three commands

• Install command — downloads the project’s dependencies using its package manager.
• Build command — prepares the production output when the project needs a build.
• Start command — runs the application that should answer requests on its assigned port.

The suggested commands are a starting point. Check the project’s scripts and requirements, especially if the repository contains several applications. A development command with a file watcher is usually not the command you want for a live production release.

Add the app’s environment values

Open the server’s Env tab to add values required by the application, such as its database connection. Use the variable names expected by the project. Save them, then redeploy for the new values to take effect.

Some values are read during the build and others when the app starts. If a first deployment fails because a required value is missing, add it and redeploy before changing unrelated setup.

Watch the deployment and open the app

1. Open Deployments in the server details.
2. Select the current deployment to read its build console. Use the stage and error to distinguish dependency installation, build, and startup problems.
3. After a successful deployment, open Logs to inspect runtime output if needed.
4. Check the app’s response, then use Domains to give it an HTTPS address.

Build output and runtime logs answer different questions. A build failure belongs in the deployment console; an error that appears when someone uses the running app belongs in Logs.

Publish your next change

1. Edit the project, save the files, and commit the intended changes.
2. Push the commit to the branch configured for this ForgeVPS server.
3. Open Deployments to follow the new release and check the commit it belongs to.
4. Open the application and verify the change you expected.

Saving a file in an editor does not push a commit. Editing files inside an existing deployed release is also not a substitute for updating the repository; a later deployment uses the repository’s code.

Use deployment history

Deployment history lets you inspect earlier releases and their build output. When you redeploy an earlier commit, ForgeVPS builds that commit again. It is not a snapshot restore of the entire application and its data.

Returning to older application code does not undo database migrations, data changes, or environment edits. Check those separately before choosing an earlier version for a production app.

• Save, commit, and push from Files
• Add the application’s domain