Sign Up
Back to Blog

Deploy a .NET API for Free on RunxBuild

Sean

Platform Writer

Jun 06, 2026
7 min read

To deploy .NET API for free, 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

Deploy a .NET API for Free on RunxBuild using GitHub build settings and RunxBuild deploy logs

What this guide covers

This guide shows how to deploy .NET API for free 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:

Before you deploy

A .NET API deploys as a running service. Build the app, expose the right port, add environment variables, and check logs before sending traffic. A prototype without logs is just a mystery with a URL.

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:

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 .NET API 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:

Root Directory: ./
Build/Start Command: dotnet publish -c Release
Public Output: service route

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.

Call the health route and one real API endpoint.

Add environment variables without leaking secrets

Backend services can use private environment variables for database URLs, API keys, tokens, and service configuration. Add those values in RunxBuild instead of committing them to GitHub.

Use one variable for each piece of configuration. Keep development values local and production values in the dashboard. The terminal should help you ship, not become a password museum.

Connect the backend to the rest of the stack

Most APIs eventually need a managed database, file storage, background jobs, or webhooks. RunxBuild keeps those next steps close to the service so the project can move from prototype to production without rebuilding the whole deployment path.

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.

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 deploy .NET API for free?

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 deploy .NET API for free 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 .NET API?

Use dotnet publish -c Release 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. Call the health route and one real API endpoint.

About the author

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