Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Nettalco/dokploy/llms.txt

Use this file to discover all available pages before exploring further.

Dokploy lets you deploy virtually any application — from Node.js APIs to Python services to static sites — directly from a Git repository or a pre-built Docker image. Once connected, Dokploy handles building, containerising, and routing your app through Traefik, with environment variable management, auto-deploy webhooks, preview environments, and one-click rollbacks all built in.

​
Supported Build Types

Dokploy supports six build strategies. Choose the one that matches how your project is structured.
Nixpacks (the default) automatically detects your language and framework, then compiles a build plan without requiring any configuration file. It works with Node.js, Python, Go, Ruby, PHP, Rust, Java, and many other runtimes — the same engine used by Railway.
# No configuration needed — Dokploy detects the runtime automatically
# Optionally override the build and start commands in the UI
Nixpacks reads your package.json, requirements.txt, go.mod, Gemfile, etc. to detect the correct build plan. You can override the detected install, build, and start commands from the application’s Build tab.

​
Creating an Application

1

Create or open a project

Navigate to the Dokploy dashboard and open an existing project, or create a new one. Projects act as logical groupings for related services.
2

Add an Application service

Inside the project, click Add Service and choose Application.
3

Choose a source

Select your source type:
  • GitHub / GitLab / Gitea / Bitbucket — connect a Git provider integration and pick your repository and branch.
  • Git — enter a raw Git clone URL and optional SSH key.
  • Docker — enter an image reference and optional registry credentials.
  • Drop — drag-and-drop a ZIP archive directly into the dashboard for a one-off deployment.
4

Configure build settings

Choose a Build Type (Nixpacks, Dockerfile, etc.) and fill in any overrides for install command, build command, start command, and root directory.
5

Set environment variables

Open the Environment tab and add any key-value pairs your application needs. Variables are injected at runtime.
6

Deploy

Click Deploy. Dokploy queues a build job, streams the logs in real time, and brings the container up once the build succeeds.

​
Build Configuration

The Build tab exposes the following settings:
SettingDescription
Build Typenixpacks, dockerfile, heroku_buildpacks, paketo_buildpacks, static, or railpack
Dockerfile pathRelative path to the Dockerfile (default: Dockerfile)
Docker context pathBuild context directory, useful for monorepos
Docker build stageTarget stage for multi-stage Dockerfile builds
Publish directoryOutput directory served by the static build type
Build pathSubdirectory within the repo to use as the build root
Build argsDocker --build-arg values passed at image build time
Clean cacheForces a clean build by ignoring the layer cache
For Nixpacks builds you can additionally override the detected install command, build command, and start command without modifying the repository.

​
Source Types

Source TypeDescription
githubOAuth app integration with GitHub
gitlabOAuth app integration with GitLab
giteaOAuth app integration with Gitea
bitbucketOAuth app integration with Bitbucket
gitRaw Git URL with optional SSH key authentication
dockerPre-built image from Docker Hub or a private registry
dropZIP archive uploaded directly through the dashboard

​
Environment Variables

Open the Environment tab on any application to manage runtime environment variables. Variables are stored securely and injected into the container at runtime. 
# Example environment variables
DATABASE_URL=postgres://user:pass@db:5432/mydb
NODE_ENV=production
PORT=3000
SECRET_KEY=supersecret
You can also set Preview Environment variables separately — these are injected only into preview deployment containers, letting you point preview builds at a staging database while production uses a different connection string.

​
Deployment Options

When Auto Deploy is enabled (the default for Git-backed sources), Dokploy registers a webhook with your Git provider. Every push to the tracked branch triggers a new deployment automatically.The triggerType field controls whether deploys fire on push events or tag events.

​
Preview Deployments

Preview deployments create a temporary, isolated environment for each open pull request. When a PR is opened against your tracked branch, Dokploy builds and deploys it to its own subdomain so you can review changes before merging.
  • Enable preview deployments on the General tab with the Preview Deployments toggle.
  • Configure a Preview Wildcard domain (e.g. *.preview.example.com) and a Preview Port.
  • Set a Preview Limit to cap the number of concurrent preview environments.
  • Preview environments inherit the application’s environment variables but can be overridden via Preview Env variables.
  • You can require Collaborator Permissions before a preview deployment is triggered, preventing untrusted forks from abusing compute.
Preview deployments are tied to pull request lifecycle events. They are automatically cleaned up when a PR is closed or merged.

​
Rollbacks

Dokploy stores rollback snapshots alongside each successful deployment. When Rollback is active, every successful deploy saves the full application context (image, mounts, ports, configuration) so you can revert instantly. To roll back:
  1. Open the application and navigate to the Deployments tab.
  2. Find the deployment you want to restore.
  3. Click the Rollback button next to that entry.
Dokploy replaces the running container with the saved image and configuration without rebuilding.

​
Scaling

Scale horizontally by increasing the Replicas count. Docker Swarm mode distributes the replicas across available nodes. Resource limits can also be set per application:
FieldDescription
ReplicasNumber of container instances to run (default: 1)
Memory ReservationSoft memory limit (e.g. 256m)
Memory LimitHard memory limit — container is OOM-killed if exceeded
CPU ReservationGuaranteed CPU share (e.g. 0.25)
CPU LimitMaximum CPU share (e.g. 1.0)

​
Port Configuration

By default Dokploy routes HTTP traffic through Traefik using the domain configuration. If your application also needs to bind a specific port, open the Ports tab to expose container ports:
  • Published Port — the host port that maps to the container.
  • Target Port — the port your application listens on inside the container.
  • Protocol — tcp or udp.
Exposing ports directly on the host bypasses Traefik and opens the port to the network. Only expose ports you intend to be publicly accessible, and always protect sensitive ports with firewall rules.

Build docs developers (and LLMs) love

Get started for freeTalk to us