One push, a URL worth sharing

Bring a repository. ServeHub detects the framework, builds it, and publishes the URL.

Runs your code as isA URL for every branchSeoul region
From push to URL — the real flow
$ git push origin mainServeHub build k3F9xQ2mLp: alice/shop@7f3a2c1 (production)[1/6] Fetching source[2/6] Planning the build[3/6] Building the image[4/6] Starting the app[5/6] Caching the image on the app nodes[6/6] Publishing the URLsReady at https://shop-alice.servehub.app

Core

Why ServeHub

Your container, run as written

No carving the app into functions, no rewrites. Next.js, Express, anything — ServeHub runs the container it builds for you.

A preview URL for every branch and PR

Whoever can open the link can review it. Every other branch and pull request gets its own URL.

A standard container, locked to nothing

There is no ServeHub-only API. The app listens on PORT and ships as a plain Docker image.

Three steps

How it works

  1. 1

    Connect GitHub

    Install the GitHub App only on the repositories you choose.

  2. 2

    Create the project

    The framework is detected automatically. Change the root directory, commands, or environment variables only when you need to.

  3. 3

    Push to deploy

    Pushing the production branch deploys right away, and commits that pile up while a build waits only get built once — the latest. Other branches and pull requests get preview URLs.

Today

What works today

No Dockerfile needed

Give it the repository and it detects the framework and builds the container image. You never write a Dockerfile.

Runs only when used

Apps sleep between requests and the next one wakes them. Resources are spent while serving, not while idle.

  • A URL for every branch and deployment

    Production, each branch, and each deployment get their own address. The production address always stays, and each project keeps the addresses of its latest 3 deployments and its 5 most recently deployed branches.

  • Zero-downtime switches

    A new version takes traffic only once it can answer it. Addresses never drop mid-deploy.

  • Encrypted environment variables

    Values are encrypted on the server and shown again never.

  • Seoul region

    Builds and apps run in the Seoul region.

Next

On the way

  • Planned

    Preview URL comments on pull requests

  • Planned

    Custom domains with automatic certificates

  • Planned

    Database, KV, and storage add-ons

Answers

Questions

Which apps can I deploy?

Anything Nixpacks knows — Node.js, Python, Go, Ruby, PHP, Java, Rust. The app just has to accept requests on the port it is given in the PORT environment variable.

Are there limits?

Each workspace can have 5 projects, 20 builds a day (the count resets at midnight KST), and 1 deployment in progress at a time; the rest wait in a queue. Each app can use up to 512 MB of memory, 1 CPU, and 1 GB of temporary disk. Apps can't send mail over SMTP ports 25, 465, or 587, so use an email API instead.

Is it free for now?

Yes — free today, within the limits above. Pricing comes when billing opens.

What about a sleeping app?

The first request after a sleep wakes the app, so that one request can take a few seconds. The ones after it answer right away.

Where is my data?

Builds and apps run in Seoul. Built images are stored in Tokyo, and project settings, build logs, and encrypted environment variables live in Firebase (Google Cloud).

Ship your first deployment today

Sign in with GitHub and pick a repository — the URL comes out in minutes.