Pushing to main and watching the app redeploy itself is the whole point of a PaaS. Dokploy does this with a webhook:

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub
    participant DP as Dokploy
    Dev->>GH: git push main
    GH->>DP: webhook POST to deploy endpoint
    DP->>DP: build image
    DP->>DP: deploy container
    DP-->>Dev: notify on success or failure
  

Connect the repository

In your Dokploy application, open the General tab and pick GitHub as the source. You have two options:

GitHub App (recommended) — install the Dokploy GitHub App on your account or org. It handles private repos, token refresh, and gives you a repo picker. Set it up once, use it for every app.

Public repository URL — paste the clone URL. Works fine for public repos, no auth needed.

Select the branch you want to track. For most setups that is main.

Turn on auto deploy

Flip the Auto Deploy toggle. Dokploy registers a webhook on the repository pointing at your server:

https://your-dokploy-domain.com/api/deploy/github

Push a commit and watch the Deployments tab. You should see a build start within a few seconds.

If nothing happens

Check these in order:

1. Webhook delivery — GitHub repo → Settings → Webhooks → click the hook → Recent Deliveries. A green check means GitHub reached your server. A red X means it did not, and the response body usually says why.
2. Your Dokploy domain resolves publicly — GitHub cannot reach localhost or a private IP. You need a real domain with a valid certificate on the Dokploy panel itself.
3. The branch matches — pushing to develop will not trigger a deploy configured for main.

Deploy only on certain paths

In a monorepo, you do not want a docs change to rebuild the API. Dokploy has a Watch Paths field in the application settings. Set it to something like:

apps/api/**
packages/shared/**

Now only changes under those paths trigger a build.

Build args and secrets

Environment variables set in Dokploy are available at runtime. If you need them at build time — a Next.js NEXT_PUBLIC_* variable, for example — add them under Build Arguments as well, and reference them in your Dockerfile:

ARG NEXT_PUBLIC_API_URL
ENV NEXT_PUBLIC_API_URL=$NEXT_PUBLIC_API_URL
RUN npm run build

Forgetting this is the single most common reason a self-hosted Next.js build works locally and ships broken.

Add a deploy notification

Under Notifications, add a Slack, Discord, or email target and tick “on deployment failure”. You want to know the build broke before a user tells you.

That is the whole loop: push, build, deploy, get told if it fails. Nothing else needs to be automated on day one.