Short answers to common questions about Dokploy Community Edition, the self-hosted Dokploy fork. For feature setup guides see the integrations page, the MCP server guide, enforced remote builds, deploy queue controls and Compose rolling replace.
Dokploy Community Edition is a community fork of Dokploy, the self-hosted platform for deploying applications, databases and Docker Compose stacks. It includes everything in upstream Dokploy v0.30.8 plus features upstream does not have and fixes ported from open upstream PRs, each ported 1:1 with credit to its original author, plus fork-only security hardening.
What is different in this fork
No. It is a community fork stewarded by Devino Solutions, and it is not affiliated with or competing against the Dokploy project. The fork exists to make new features available faster, and every ported change credits its original upstream author.
On a clean Linux server with root access, the same requirements as Dokploy, run the install script from this site. To install a specific version set the DOKPLOY_VERSION environment variable first, and to update an existing installation run the script with the update argument. The commands are shown below.
curl -sSL https://dokploy-community.devino.ca/install.sh | sh
# a specific version
export DOKPLOY_VERSION=v0.30.8-community.40
curl -sSL https://dokploy-community.devino.ca/install.sh | sh
# update an existing installation
curl -sSL https://dokploy-community.devino.ca/install.sh | sh -s update
Run one docker service update command against the dokploy service on your existing server, pointing it at the ghcr.io/devinosolutions/dokploy-community image. It keeps every application, database, domain and setting because the extra migrations are additive, and the image is public so no registry login is required. The command is shown below.
docker service update \
--image ghcr.io/devinosolutions/dokploy-community:v0.30.8-community.40 \
--with-registry-auth \
dokploy
Yes. Update the dokploy service back to the official dokploy/dokploy image at the version you want, for example v0.30.8. The extra tables and columns that this fork adds are simply ignored by official Dokploy.
docker service update --image dokploy/dokploy:v0.30.8 --with-registry-auth dokploy
Yes. Recent release images are multi-arch, covering linux/amd64 and linux/arm64, and are built by CI from the release commit. The public image is ghcr.io/devinosolutions/dokploy-community, with versioned tags, a latest tag for the latest release and a canary tag for the latest build.
Dokploy Community Edition has a built-in remote MCP server, so you do not need to run a separate npx process or create an API key. Add it to Claude Code with the command shown below, using your own panel address, then run /mcp, choose Authenticate and sign in once in the browser through OAuth. An MCP client that cannot use the browser sign-in can send a Dokploy API key in the x-api-key header instead.
claude mcp add --transport http --scope user dokploy https://<host>/api/mcp
# optional: authenticate with a Dokploy API key instead of OAuth
claude mcp add --transport http --scope user dokploy https://<host>/api/mcp --header "x-api-key: <key>"
MCP server guide: sign-in flow, scopes and limits and the remote MCP server in the README
Upstream Dokploy rejected webhook request bodies larger than 1 MB, so a large GitHub push, for example one with many commits or changed files, was skipped and the request was answered with HTTP 413 Payload Too Large. Since v0.30.8-community.1 the Community Edition accepts deploy webhook payloads up to 25 MB, so those pushes trigger a deploy.
Webhook payload limit change on GitHub
Upstream Dokploy set the status of a service back to idle when you saved the provider settings of an application, or disconnected the Git provider of an application or compose stack, so a running service could look stopped until its next deploy. Since v0.30.8-community.1 the Community Edition keeps the current status when you save provider settings.
Yes, in multi-server mode. Open the Application, Compose stack or database you want to move and start the transfer to another server. The move runs in two phases, scan and then execute, and uses a copy-based cutover: the source is stopped, its data is copied to the destination, and the service switches to the new server only after the copy fully succeeds. If anything fails the source is restarted and left untouched, so the service keeps running where it was.
Server transfer pull request on GitHub
Open Settings → Integrations, choose Connect DoDomain and paste the server-side secret key of your DoDomain app, which starts with dd_sk_. Press Test connection to fill in the App ID from the key. Leave the Base URL at its default unless you run a self-hosted DoDomain, and note that it must use https, with http allowed only for localhost. Then press Connect.
Connect the Uptimely integration in Settings → Integrations with a project API key from Uptimely, and turn on AI write operations for that project in Uptimely. Then open an application, compose stack or database, go to its Monitoring tab and press Monitor with Uptimely. Dokploy creates one Website monitor per HTTPS domain, or a Port monitor for a database with an external port, and the checks run every 5 minutes.
Uptimely checks the exact URL of the domain, which is its host plus its path. If that URL answers 404 or another error, the monitor shows Offline even when the rest of the site works. Open the URL in a browser to see what it returns, then fix the application or the domain path. Monitors cannot be deleted from Dokploy, so delete an obsolete monitor in Uptimely itself.
Yes. The container log viewer has a Send a command box that sends what you type to the container as input. The viewer attaches to the container only when you send a command and never forwards signals, so looking at logs does not restart services that exit on SIGHUP. Since v0.30.7-community.9 the input keeps working after the container restarts, including for TTY containers.
The fork merges upstream release tags, never the moving upstream canary branch, so it always tracks a tested and published state. It diverges only for features that upstream lacks, and when upstream ships an equivalent the fork drops its own version and takes the upstream one. Releases are versioned as the upstream version plus a community release number, for example v0.30.8-community.40.
It reports unhandled backend errors, meaning crashes and internal server errors, to a Devino-hosted Sentry instance. An event contains the stack trace, the error message and the fork version. No environment variables, secrets, deployment logs, request data or personal information are sent, and the reporting server hostname is stripped. You can opt out by setting DOKPLOY_DISABLE_SENTRY=true on the dokploy service, and the DO_NOT_TRACK=1 convention is also respected.