Dokploy Community Edition is a self-hosted fork of Dokploy. It adds native integrations that you connect once per organization and then use from the pages of your services. This page covers each one: what it does, what you need, how to connect it, and its limits.
The Integrations page (/dashboard/settings/integrations) shows cards for Uptimely, DoDomain and Snapvisor. Each organization has one connection per product, so connecting again opens an edit instead. Secrets are write-only: after you save a key or token, Dokploy only shows its last four characters, and leaving the field blank while editing keeps the stored value. Every connect dialog has a Test connection button, so you can check the credentials before saving.
Uptimely: uptime, SSL and domain monitoring
Uptimely runs checks from outside your server. With the integration, each application, compose stack or database gets an opt-in uptime panel on its Monitoring tab: a status pill, a 30-day timeline per monitor, and a link to each monitor in Uptimely. Checks run every 5 minutes. Uptimely also publishes a Dokploy × Uptimely page that walks through the integration with screenshots.
What you need
An Uptimely project and one of its project API keys. Create the key in Uptimely under Settings → API Keys. It is locked to a single project.
AI write operations turned on for that project (Uptimely → Settings → API Keys). Creating monitors and running probes are write operations, and Uptimely refuses them while the setting is off. Reading status works either way.
How to connect
Open Settings → Integrations and press Connect Uptimely.
Fill in Name, Project API key and Project ID. You can leave Project ID blank and press Test connection: Dokploy lists the projects the key can reach and fills it in when there is exactly one.
Leave Base URL at https://app.getuptimely.com unless you run a self-hosted Uptimely.
Optionally set Status page slug. When it is set, the public status badge is shown on each monitored service. Only public status pages have a badge.
Press Connect.
How to monitor a service
Open the service and go to its Monitoring tab.
In the Uptime by Uptimely panel, press Monitor with Uptimely. Nothing is created until you press it.
For applications and compose stacks, tick Also add SSL certificate and domain monitors if you want them as well.
For applications and compose stacks, optionally fill in Path to check (optional), for example /health. It is added to each domain’s URL, so pick a path that returns 200 (a 2xx or 3xx counts as up). Leave it blank to monitor the domain’s own URL. The path is only used when the monitors are first created.
Below the path, the Reachability check makes a real request to each URL the monitors would watch and shows what it answers. A URL that answers an error or does not respond gets a warning that Uptimely will report it Offline, before any monitor exists. Press Check to run it again.
Use Run probe now to run a check immediately, Add monitors for new domains after you add a domain (it creates a Website monitor for each HTTPS domain added since the service was linked and keeps the existing monitors), and Open in Uptimely to jump to a monitor.
What gets created
Applications and compose stacks: one Website monitor per HTTPS domain. Wildcard domains and preview-deployment domains are skipped. With the checkbox ticked, each distinct HTTPS host also gets an SSL Certificate monitor and a Domain monitor.
Databases: one Port monitor for the database’s external port. Expose the database on an external port first.
Monitors that already exist for the same target are not created twice.
Limits to know about
One Website monitor is created per HTTPS domain. A service with no HTTPS domain, or a database with no external port, has nothing to monitor: the Monitor with Uptimely button is disabled and the panel says what to add (an HTTPS domain, or an external port).
Uptimely checks the exact URL: the domain’s 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 Uptimely sees.
Once monitors exist, a Website monitor that is Offline shows a note under the timeline. If the service answers 404 there, unlink it and monitor again with a path such as /health.
Monitors cannot be deleted from Dokploy, because Uptimely’s API has no monitor delete. Unlink only makes Dokploy forget the monitors for that service. Disconnecting the integration removes the stored API key and every link. In both cases the monitors keep running in Uptimely until you delete them there.
One Uptimely project is connected per organization.
Deploy heartbeat (applications and compose stacks)
The panel has an optional Deploy heartbeat. Press Add deploy heartbeat to create an Incoming Request monitor in Uptimely. After every successful deploy, Dokploy pings that monitor, so Uptimely alerts you when a service stops deploying on schedule.
Uptimely does not share a heartbeat monitor’s secret over its API. After the monitor is created, open it in Uptimely (Open monitor settings), copy the heartbeat URL or secret key, paste it into the panel and press Save key. No ping is sent until the key is saved.
A new heartbeat monitor expects a ping every 5 minutes. Set the interval and grace period that suit the service in the monitor’s Settings in Uptimely, otherwise it reports Offline between deploys.
The ping is a short request that never fails or slows a deploy. If Uptimely is unreachable, Dokploy logs the failure without the key and carries on.
Remove deletes the link in Dokploy and stops the pings. Uptimely has no monitor delete tool, so the monitor stays in Uptimely until you delete it there. Unlink on the uptime monitors leaves the heartbeat alone.
Snapvisor: visual testing on preview deployments
Snapvisor diffs screenshots from your CI against a baseline and lets your team approve or reject the changes. With the integration, each preview deployment of an application shows the review status of its build.
What you need
A Snapvisor account, a personal access token (created in your Snapvisor account settings) and your account slug, which is the my-team in app.snapvisor.io/my-team/my-project.
The Snapvisor CLI running in your own CI. Screenshots are still captured and uploaded there. Dokploy does not create builds: it finds the build Snapvisor already created for the commit it just deployed and shows its status.
How to connect
Open Settings → Integrations and press Connect Snapvisor.
Fill in Name, Personal access token and Account slug.
Leave Base URL at https://api.snapvisor.io unless you run a self-hosted Snapvisor.
Press Test connection, then Connect.
How to turn it on for an application
Open the application, go to Preview Deployments and open the preview deployment settings.
Under Visual testing (Snapvisor), pick the Snapvisor project. Off is the default.
Each preview card now shows a Snapvisor badge: Pending, No changes, Changes detected, Approved, Rejected, Error or Expired, with a refresh button and a Review in Snapvisor link.
Branch and production deployments
The same link works for regular deployments. On the Deployments tab of an application or compose service, pick the Snapvisor project under Visual testing (Snapvisor) (it appears once Snapvisor is connected). Every finished deployment of that service that recorded its full commit SHA then shows the same badge, with a refresh button and a Review in Snapvisor link. A commit that has no build yet reads No build yet; an expired token, a rate limit or an unreachable Snapvisor reads Unavailable with the reason on hover. None of these affects the list. The commit is only trusted for git-sourced services (GitHub, GitLab, Bitbucket, Gitea, Git): for Docker-image, upload and raw-compose services the deployment text is free-form, so no badge or notification is produced from it.
Get notified when there are changes to review
Turn on Snapvisor Visual Changes on a notification channel (Settings → Notifications). When a deployment of a linked service, whether production, branch or preview, has a Snapvisor build for its commit and that build reaches Changes detected, the channel gets one message with the service, environment, branch, short commit, the number of changed snapshots and the review link.
Dokploy finds out by asking Snapvisor itself (outbound, every few minutes), so it works on a panel that Snapvisor cannot reach. A deployed commit is watched for 6 hours; if its build never appears or never needs a review, nothing is sent. Each commit of a service is announced at most once, even across restarts and redeploys of the same commit.
Limits to know about
The build is looked up by the full 40-character commit SHA of the preview’s latest deployment. If your CI has not produced a build for that exact commit yet, the badge reads Not registered; refresh once the build exists.
The lookup applies to application and compose services. Dokploy polls while a build is still pending and stops once it reaches a final status.
Disconnecting removes the stored token and every application’s project link. Builds already created in Snapvisor are unaffected.
DoDomain: custom-domain connect and DNS verification
DoDomain lets the owner of a domain connect it to your service through a hosted flow: one-click Cloudflare sign-in, Domain Connect with the DNS provider, or guided manual DNS setup. DoDomain verifies the records, and Dokploy asks DoDomain for the result on its own, so it works on a panel that is not reachable from the internet. If the panel is public, DoDomain’s webhooks add instant updates.
What you need
A DoDomain app and its server-side secret key from the DoDomain dashboard.
Optional: the Dokploy panel on a public HTTPS URL (Settings → Web Server). Saving the integration then also registers a webhook at /api/webhooks/dodomain, so DoDomain can report results instantly. Without it, Dokploy polls DoDomain.
How to connect
Open Settings → Integrations and press Connect DoDomain.
Fill in Name, Secret key and App ID. You can leave App ID blank and press Test connection to fill it in from the key.
Leave Base URL at https://app.dodomain.io unless you run a self-hosted DoDomain.
Press Connect. The card shows that status is polled and whether the optional webhook is registered.
How to use it
On a service’s Domains tab, add the domain the customer owns. In the domain dialog, Check DNS shows which provider hosts it and how its owner will connect.
In the domain’s row, open the DoDomain actions menu and choose Send connect link. Dokploy shows the link, the DNS records it will request and when it expires. Copy connect link copies the active link and Check now asks DoDomain for the current state right away and shows the result.
Send the link to the domain’s owner. Dokploy checks DoDomain every couple of minutes, and the domain row shows DNS verified once the records match. Until then it shows Awaiting domain owner, and DNS verification failed when the records no longer match. Verified domains are re-checked every 30 minutes, so a broken connection is noticed and sent to your notification providers.
Limits to know about
Only concrete hostnames can be connected. Wildcard hosts and generated sslip.io and traefik.me names cannot.
DoDomain only delivers webhooks to a public HTTPS address. If the panel is served on a private address (for example a Tailscale *.ts.net name, a .local or .internal host, or a private IP), DoDomain refuses to register the webhook or cannot deliver to it. Nothing breaks: Dokploy saves the integration, polls DoDomain for status, and the card says polling is in use. Serve the panel on a public HTTPS URL if you also want instant webhook updates. Check now is disabled until a connect link has been sent for the domain.
Connect links created before this polling existed carry no stored session token, so Dokploy cannot run the live DNS check for them; it still finds the connection once the owner finishes the flow. Send a new link to get the full polling behavior.
A DNS verification failure is sent to the notification providers that are subscribed to deploy failures.
Disconnecting removes the stored secret key and deletes the webhook endpoint from DoDomain. Domains keep their current verification state.
Sendly and Notifly: notification providers
Sendly and Notifly are notification providers, so they live in Settings → Notifications rather than on the Integrations page. Press Add Notification, then under Select a provider choose Sendly or Notifly. Choose which events should notify it, press Test Notification to send a test, then Create.
Sendly (sendly.now) sends notifications as email. Fields: Name, API Key, Base URL (defaults to https://app.sendly.now, the base URL of your Sendly instance), From Address and one or more To Addresses.
Notifly (notifly.io) triggers a Notifly workflow for each notification. Fields: Name, API Key, Base URL (defaults to https://api.notifly.io), Workflow Key (the identifier of the workflow to trigger) and an optional Subscriber ID that defaults to dokploy.
Uptimely (getuptimely.com) is also a provider. Choose Uptimely under Select a provider. When a deploy fails it declares an incident in the Uptimely project, and the next successful deploy of the same service resolves it. Fields: Name, API Key, Project ID, Base URL (defaults to https://app.getuptimely.com) and an optional Resolved state ID. It only reacts to the App Build Error switch (a success always resolves an open incident).
The Uptimely project needs AI write operations turned on, or Uptimely refuses to declare and resolve incidents. Dokploy logs the refusal and the deploy carries on.
Uptimely has no tool that lists incident states, so Dokploy reads the Resolved state from the project’s existing incidents. If no incident has been resolved there yet, set Resolved state ID (the id of the project’s Resolved incident state).
Test Notification only checks that the key can see the project. It never declares an incident.