Auto Deploy an App From GitHub on RunxBuild

To auto deploy app from GitHub, connect your GitHub repository to RunxBuild, choose the right deployment type, set the build or start command, add required environment variables, and deploy. RunxBuild builds the project, publishes a live route, shows deploy logs, and gives you a path to add domains, databases, and backend services as the project grows.

That is the short version. The rest is where the deploy usually succeeds or quietly trips over a folder named dist.

Table of contents

• What this guide covers
• Before you deploy
• Step 1: Push the project to GitHub
• Step 2: Create the RunxBuild deployment
• Step 3: Configure build settings
• Step 4: Add environment variables
• Step 5: Deploy and verify
• Troubleshooting
• FAQ

What this guide covers

This guide shows how to auto deploy app from GitHub with a practical deployment flow: prepare the repository, set the build or start command, add environment variables, deploy, connect domains, and troubleshoot the common mistakes.

You do not need a pile of platform tabs open to ship the first version. You need the project in GitHub, the right RunxBuild resource, and logs clear enough to tell you what happened.

You will cover:

• the repository setup
• the RunxBuild deployment type
• the build or start command
• the output directory or service route
• environment variables
• deployment logs
• custom domains
• common failure modes

Useful RunxBuild docs:

• RunxBuild deployment docs
• GitHub connection guide
• Custom domain setup

Before you deploy

Auto deployment connects a GitHub repo to a repeatable build. Push code, RunxBuild detects the project shape, runs the build path, and publishes the result with logs. The useful part is not magic. It is visible automation.

Run the project locally first. A remote deploy should not be the first time the app meets production settings.

# install dependencies
npm install

# or use the package manager your project already uses

Then run the framework-specific build or start command. If the project fails locally, fix that first. Remote build logs are useful, but they should not be the first witness.

For background reading, use these authoritative references:

• GitHub documentation
• official documentation
• official documentation

Step 1: Push the project to GitHub

RunxBuild deploys from GitHub. Commit the working project and push it to the branch you want to deploy.

git add .
git commit -m "Prepare app for deployment"
git push origin main

If this is a new repository, create it first and add the remote:

git remote add origin https://github.com/YOUR-USER/YOUR-REPO.git
git push -u origin main

Do not commit secrets. Put production credentials in RunxBuild environment variables.

Step 2: Create the RunxBuild deployment

Open the RunxBuild dashboard and create a new deployment for the project.

Choose the resource type that matches the app:

• Static Website for static builds and frontend apps
• Service for APIs, backends, and containers
• WordPress for WordPress sites
• Database when the app needs persistent data

Select the GitHub repo and branch. Use a name you will understand in six months. final-final-api-v3 is funny once and annoying forever.

Step 3: Configure build settings

Use these settings as the starting point:

Repository: GitHub
Build Command: detected from your repository
Output: detected output folder

If the app lives in a monorepo, set the root directory to the subfolder that contains the app.

Root Directory: apps/web

Most failed deployments come down to two settings: what command runs, and where the result lives. Get those right and most of the drama leaves the room.

Step 4: Add environment variables

Add production environment variables in RunxBuild before deploying.

Common examples:

API_URL=https://api.example.com
DATABASE_URL=postgres://user:password@host:5432/db
NODE_ENV=production
PORT=3000

Static frontends can only safely use public variables. Backends can use private secrets because the code runs server-side. If users can download the bundle, assume they can read anything inside it.

Step 5: Deploy and verify

Click deploy and watch the logs.

Check these before calling the deployment finished:

• The build completes without dependency errors.
• The live route opens.
• Required assets load.
• API requests hit the production endpoint.
• Environment variables have the expected values.
• Logs show no startup crash.
• The custom domain works after DNS propagation.

Push a small change and confirm the redeploy starts automatically.

Make auto deploys boring on purpose

The goal is not to hide everything. The goal is to remove repeated setup while keeping logs, environment variables, routes, and rollback visible. A deploy that fails silently is not automation. It is a haunted checkbox.

Use manual control when the app needs it

Auto detection works best for common project shapes. If the project uses a monorepo, a custom build script, or separate frontend and backend folders, set the root directory and commands explicitly.

Troubleshooting

The build command fails

Run the same command locally. If it fails there, the issue is in the project, not the platform. Check dependencies, lockfiles, and case-sensitive imports.

The deploy succeeds but the page or API does not load

Check the publish directory for static apps and the port for services. The platform can only route what the app actually exposes.

Environment variables are missing

Add them in RunxBuild and trigger a new deploy. Build-time variables are baked into static output, so changing them after the build is not enough.

The app works locally but not in production

Look for local-only paths, missing production config, and secrets that were never added to the dashboard. Localhost is not a production architecture. It just dresses confidently.

Production checklist before launch

Use this final pass before sharing the URL with users:

• Confirm the deployed branch is the branch you expected.
• Save the build command in the dashboard, not only in your memory.
• Keep environment variables named clearly.
• Add a health check or simple test route for services.
• Keep deploy logs close during the first real traffic.
• Add a custom domain only after the generated route works.

This is the part that makes the deploy repeatable. Fast is useful. Repeatable is what keeps the project alive after the first version ships.

Final launch pass

Before you move traffic, run one practical check from start to finish. Push a small change, watch the deploy start, open the generated route, test the main user path, and read the latest logs. If that path works, the deployment is not just live. It is repeatable.

That is the real production upgrade: fewer disconnected tools, fewer guessing games, and a clear place to see what changed when the app starts acting clever.

FAQ

How do I auto deploy app from GitHub?

Push the project to GitHub, create the matching RunxBuild resource, set the build or start command, add environment variables, and deploy. RunxBuild publishes the result with logs and a live route.

Can I auto deploy app from GitHub without a credit card?

RunxBuild includes a free monthly allocation for small projects. Heavier usage, larger instances, or production traffic may need a paid plan.

What command should I use to deploy a app?

Use detected from your repository as the starting point, then adjust it for your project. The exact command depends on the framework, package manager, and repository layout.

Do I need environment variables?

Use environment variables for API URLs, database connections, tokens, and configuration that should change between local and production environments.

Can I add a custom domain?

Yes. Deploy the app first, verify the generated RunxBuild route, then add the custom domain and update DNS.

What should I check after deployment?

Open the live route, check logs, test navigation, and verify production behavior. Push a small change and confirm the redeploy starts automatically.

About the author

Written by Sean, Platform Writer at RunxBuild. Last updated: June 6, 2026.