Deploy your first app on DployHub

DployHub turns a repository or a Docker image into a running app with its own HTTPS address. You never pick or manage servers: you point us at your code, confirm a few settings and we build, run and keep it online. This guide walks through the whole flow from an empty account to a live app.

Before you start

• An account. Sign up takes a minute, then you land on the dashboard at /portal.
• Your code in a GitHub repository, any public Git URL, or a public Docker image.
• A project we can recognise at its root folder: a Dockerfile, a package.json (Node.js), a requirements.txt, pyproject.toml or Pipfile (Python), or an index.html (static site).

Create the app

1. 1

   Open New app

   In the dashboard go to Apps, then New app, or open /portal/apps/new directly.

2. 2

   Choose a source

   Pick GitHub (connect your account, then choose a repository and branch), Public Git URL (paste an https:// or git@ URL and a branch) or Docker image (a public image name with a tag, such as nginx:1.27-alpine).

3. 3

   Choose how to build it

   Leave "Figure it out for me" selected and we detect the framework, build command, start command and port. You can instead pick Use my Dockerfile, Node.js, Python or Static website.

4. 4

   Name your app

   The name becomes a slug and your addresses: live at https://<slug>.apps.dployhub.com and staging at https://<slug>-staging.apps.dployhub.com. Renaming the app later keeps the same URLs.

5. 5

   Pick resources

   Choose vCPU, memory and storage for live. The monthly price updates as you change them, so you know the cost before you create anything. The default is 0.5 vCPU, 512 MB and 5 GB for ₹255 a month.

6. 6

   Create and deploy

   We clone or pull your source, build it, start it and check that it answers. The first deploy of a new app goes live automatically.

Watch the build

Build logs stream live in the Deployments tab of your app, so you can see every install and compile step as it happens. Builds can run for up to 30 minutes. Once the image is ready we start the new container and wait up to 90 seconds for it to answer HTTP on the health check path. When it does, traffic switches to it.

What you get

• Two environments: staging and live, each with its own address, environment variables and custom domain.
• Automatic HTTPS on both addresses, and on any custom domain you add later.
• Logs, CPU and memory metrics and uptime for each environment.
• Zero-downtime releases: if a new version fails to start, the running version keeps serving.

Next steps

After the first release, new deploys go to staging first. Check the staging address, then press Go live to promote the exact same image to live, with no rebuild. From here you will probably want to add environment variables, connect a custom domain and, if you used GitHub, rely on auto-deploy on push.

If the build or release fails, the deploy is marked failed with the last 50 log lines and a plain-language reason. Start with Build failed, and if you are still stuck, raise a ticket from Help & tickets with the app and deployment attached.