Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions apps/docs/content/docs/core/account-security.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
title: Account Security
description: "Protect your Dokploy account with passkeys (WebAuthn) and two-factor authentication."
---

import { Callout } from "fumadocs-ui/components/callout";

Dokploy supports two mechanisms to secure panel access, and they can be combined: **passkeys** for passwordless sign-in and **two-factor authentication (2FA)** on top of password logins.

## Passkeys

Passkeys are a passwordless sign-in method based on WebAuthn. Instead of typing a password (and a 2FA code), you authenticate with your device — Touch ID, Face ID, Windows Hello, or a hardware security key like a YubiKey. The credential never leaves your device and is resistant to phishing: it only works on your Dokploy panel's domain.

### Registering a passkey

1. Go to **Settings → Profile**.
2. In the **Passkeys** section, click add and follow your browser's prompt (fingerprint, face, PIN, or security key).
3. Give it a recognizable name — you can register several (e.g. laptop + phone) and remove them individually at any time.

### Signing in

On the login page, use the passkey option and pick the credential — no password or 2FA code required.

<Callout type="info">
Register at least two passkeys (or keep your password + 2FA working) so losing a device doesn't lock you out.
</Callout>

## Two-Factor Authentication (2FA)

2FA adds a time-based one-time code (TOTP) to password logins, from any authenticator app (Google Authenticator, 1Password, Authy, etc.).

### Enabling 2FA

1. Go to **Settings → Profile**.
2. In the **2FA** section, click enable and scan the QR code with your authenticator app.
3. Confirm with a generated code, and store the backup codes somewhere safe — they are the recovery path if you lose the authenticator.

Once enabled, password sign-ins require the current code from your app.

## Which one should I use?

- **Passkeys** are the strongest and most convenient option — phishing-resistant and no codes to type. Prefer them for day-to-day sign-in.
- **2FA** protects the password flow, which remains available as a fallback. If you keep using passwords, enable it.
- Using both gives you a secure fallback chain: passkey for daily use, password + 2FA if a device is unavailable.

<Callout type="info">
Organization owners on Dokploy Cloud and self-hosted instances with SSO can additionally enforce sign-in through their identity provider — see the SSO documentation.
</Callout>
32 changes: 32 additions & 0 deletions apps/docs/content/docs/core/dns-providers/cloudflare.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
title: Cloudflare
description: "Connect Cloudflare to create A/CNAME records for your domains from Dokploy."
---

import { Callout } from "fumadocs-ui/components/callout";

## Create an API Token

1. In the Cloudflare dashboard, go to **My Profile → API Tokens → Create Token**.
2. Use the **Edit zone DNS** template, or create a custom token scoped to **Zone → DNS → Edit**.
3. Under **Zone Resources**, select the zones you want Dokploy to manage — either all zones or specific ones.
4. Create the token and copy it — it is only shown once.

<Callout type="warn">
Avoid the account-wide Global API Key. Scope the token to Zone → DNS → Edit for only the zones Dokploy needs.
</Callout>

## Configuration

In **Settings → DNS Providers**, add a provider, choose **Cloudflare** and fill in:

- **Name**: the identifier for this provider, e.g. `cloudflare-main`.
- **API Token**: the token created above.

Use **Test Connection** to validate the token before saving.

## Managing Records

Click **View Domains** on the provider row to list the zones the token can see, then click a zone to view and manage its **A** and **CNAME** records. See [DNS Providers](/docs/core/dns-providers) for the full record form reference.

Cloudflare's default/automatic TTL is used when the **TTL** field is left empty.
57 changes: 57 additions & 0 deletions apps/docs/content/docs/core/dns-providers/index.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
title: DNS Providers
description: "Connect Cloudflare or AWS Route53 to create and manage A/CNAME records for your domains without leaving Dokploy."
---

import { Callout } from "fumadocs-ui/components/callout";

## What are DNS Providers?

DNS Providers let you connect Dokploy to Cloudflare or AWS Route53 so you can browse your zones and create the **A** or **CNAME** record a domain needs, instead of switching to your DNS provider's dashboard by hand.

<Callout type="info">
Enterprise feature. Managing DNS providers is covered by the `dnsProvider` permission resource — grant it granularly with a [custom role](/docs/core/enterprise/custom-roles), or use it as owner/admin.
</Callout>

Supported providers:

- [Cloudflare](/docs/core/dns-providers/cloudflare)
- [AWS Route53](/docs/core/dns-providers/route53)

## Creating a Provider

Go to **Settings → DNS Providers** and click to add a provider. Pick **Cloudflare** or **AWS Route53**, give it a name, and fill in the credentials — see the provider pages for exact steps. Use **Test Connection** to validate the credentials before saving.

Credentials are masked in the UI after saving; leaving a masked field untouched on an edit keeps the stored value. The provider type is locked once created — to switch providers, create a new one.

## Managing Records

From the provider list, click **View Domains** to open the zones your credentials can see. Click a zone to expand its records:

- Records of type **A** and **CNAME** are editable and deletable from Dokploy.
- Other record types (MX, TXT, NS, etc.) returned by the provider are listed read-only.

To add a record, click **Add Record** and fill in:

- **Type**: A or CNAME.
- **Name**: the hostname, e.g. `app.example.com`. Use `@` for the zone's root/apex domain.
- **Content**: labeled **IPv4 Address** for A records or **Target** for CNAME records. For A records, an optional **Fill from server** dropdown auto-fills this with the public IP of the Dokploy panel server or any registered remote server.
- **TTL** (optional): leave empty for the provider's automatic/default TTL.

<Callout type="warn">
Deleting a record from this screen removes it from the actual DNS provider, not just from Dokploy — the confirmation dialog calls this out explicitly.
</Callout>

## Relationship to Domains

DNS Providers is a standalone integration under **Settings**. It is not (yet) wired into the "add domain" flow on applications or Compose services — creating a domain there still expects the DNS record to already point at your server. Use DNS Providers to create that record first (or in parallel), then add the domain in the service as usual.

## Access Control

Managing DNS providers is covered by the `dnsProvider` permission resource:

- **Owners and admins** can create, update, delete and test providers.
- **Members** can read configured providers and zones.
- With an enterprise license, **custom roles** can grant each action (`read`, `create`, `update`, `delete`) granularly.

Every create, update and delete on a DNS provider is recorded in the [Audit Log](/docs/core/enterprise/audit-logs).
7 changes: 7 additions & 0 deletions apps/docs/content/docs/core/dns-providers/meta.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
{
"title": "DNS Providers",
"pages": [
"cloudflare",
"route53"
]
}
48 changes: 48 additions & 0 deletions apps/docs/content/docs/core/dns-providers/route53.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
title: AWS Route53
description: "Connect AWS Route53 to create A/CNAME records for your domains from Dokploy."
---

import { Callout } from "fumadocs-ui/components/callout";

## Create IAM Credentials

Create an IAM user (or role) with programmatic access and a least-privilege policy for the hosted zones Dokploy should manage:

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:ListHostedZones",
"route53:ListResourceRecordSets",
"route53:ChangeResourceRecordSets"
],
"Resource": "*"
}
]
}
```

Avoid root account credentials — scope a dedicated IAM user to this policy.

## Configuration

In **Settings → DNS Providers**, add a provider, choose **AWS Route53** and fill in:

- **Name**: the identifier for this provider, e.g. `route53-main`.
- **Access Key ID / Secret Access Key**: the IAM credentials.

Use **Test Connection** to validate the credentials before saving.

<Callout type="info">
Route53 is a global service, so there is no region field — Dokploy talks to it directly. There is also no custom endpoint override: this integration only works against real AWS, not LocalStack or other Route53-compatible emulators.
</Callout>

## Managing Records

Click **View Domains** on the provider row to list your hosted zones, then click a zone to view and manage its **A** and **CNAME** records. See [DNS Providers](/docs/core/dns-providers) for the full record form reference.

Route53 defaults the **TTL** to `300` seconds when the field is left empty. Since Route53 has no native record ID, renaming a record's name or type is applied as a delete of the old record plus creation of the new one.
2 changes: 2 additions & 0 deletions apps/docs/content/docs/core/enterprise/audit-logs.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,8 @@ Audit Logs track every meaningful action in your organization:
- **Infrastructure** — Changes to servers, registries, certificates, SSH keys, and S3 destinations.
- **Backups & Schedules** — Creating, updating, or deleting backups, volume backups, and scheduled jobs.
- **Notifications** — Changes to notification providers.
- **Secrets Providers** — Creating, updating, or deleting connections to external secret managers (HashiCorp Vault / OpenBao, Infisical, AWS Secrets Manager, Doppler, Azure Key Vault, Scaleway Secret Manager). See [Secrets Providers](/docs/core/secrets-providers).
- **DNS Providers** — Creating, updating, or deleting DNS provider connections (Cloudflare, AWS Route53). See [DNS Providers](/docs/core/dns-providers).

## Filtering

Expand Down
27 changes: 27 additions & 0 deletions apps/docs/content/docs/core/enterprise/custom-roles.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -199,6 +199,15 @@ Manage notification providers (Slack, Discord, Telegram, etc.).
- **Update** — Modify notification configurations.
- **Delete** — Remove notification providers.

### Tags

Manage tags used to organize and filter projects.

- **Read** — View tags.
- **Create** — Create new tags.
- **Update** — Edit existing tags.
- **Delete** — Remove tags.

### Logs

View service and deployment logs.
Expand All @@ -217,6 +226,24 @@ View the audit log of actions performed in the organization.

- **Read** — View audit log entries.

### Secrets Providers

Manage connections to external secret managers (HashiCorp Vault / OpenBao, Infisical, AWS Secrets Manager, Doppler, Azure Key Vault, Scaleway Secret Manager) used to reference secrets in environment variables. See [Secrets Providers](/docs/core/secrets-providers).

- **Read** — View provider names and secret names (powers the `${{vault.*}}` autocomplete).
- **Create** — Add new secrets providers.
- **Update** — Edit existing provider configuration and assignments.
- **Delete** — Remove secrets providers.

### DNS Providers

Manage connections to DNS providers (Cloudflare, AWS Route53) used to automatically create A/CNAME records for domains. See [DNS Providers](/docs/core/dns-providers).

- **Read** — View configured DNS providers.
- **Create** — Add new DNS providers.
- **Update** — Edit existing DNS provider configuration.
- **Delete** — Remove DNS providers.

## Creating a Custom Role

1. Go to **Settings → Custom Roles**.
Expand Down
3 changes: 3 additions & 0 deletions apps/docs/content/docs/core/meta.json
Original file line number Diff line number Diff line change
Expand Up @@ -27,8 +27,11 @@
"(S3-Destinations)",
"(Git-Sources)",
"(Users)",
"account-security",
"(Notifications)",
"registry",
"secrets-providers",
"dns-providers",
"ssh-keys",
"certificates",
"backups",
Expand Down
55 changes: 55 additions & 0 deletions apps/docs/content/docs/core/secrets-providers/aws.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
title: AWS Secrets Manager
description: "Use AWS Secrets Manager secrets in your Dokploy environment variables."
---

import { Callout } from "fumadocs-ui/components/callout";

## Create IAM Credentials

Create an IAM user (or use an existing one) with programmatic access and a least-privilege policy for the secrets Dokploy should reach:

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:ListSecrets"],
"Resource": "arn:aws:secretsmanager:*:*:secret:dokploy/*"
}
]
}
```

`ListSecrets` is only used to power the autocomplete; you can omit it and the provider still resolves references.

## Configuration

In **Settings → Secrets → Add Provider**, choose **AWS Secrets Manager** and fill in:

- **Name**: the identifier used in references, e.g. `aws-sm`.
- **Region**: the region your secrets live in, e.g. `us-east-1`.
- **Access Key ID / Secret Access Key**: the IAM credentials.
- **Endpoint** (optional): a custom endpoint for VPC endpoints or API-compatible emulators (e.g. LocalStack). Leave empty for regular AWS.

Use **Test Connection** to validate the credentials before saving, then assign the projects/environments where the provider may be used.

## Reference Format

References use the secret **name** (not the ARN). Two forms are supported:

```bash
# Raw SecretString — returns the value exactly as stored
API_TOKEN=${{vault.aws-sm.api-token}}

# JSON secrets — extract a single field with :<field>
DB_PASSWORD=${{vault.aws-sm.prod/database:password}}
DB_HOST=${{vault.aws-sm.prod/database:host}}
```

If the secret stores a JSON object (the common pattern for database credentials), append `:<field>` to pick one key. Without a field, the whole `SecretString` is injected as-is — useful for apps that parse a JSON config blob from a single variable.

<Callout type="warn">
Binary secrets are not supported — only `SecretString` values.
</Callout>
49 changes: 49 additions & 0 deletions apps/docs/content/docs/core/secrets-providers/azure.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
title: Azure Key Vault
description: "Use Azure Key Vault secrets in your Dokploy environment variables."
---

import { Callout } from "fumadocs-ui/components/callout";

Dokploy authenticates with an **App Registration** (service principal) using the OAuth2 client credentials flow.

## Create an App Registration

1. In the Azure Portal, go to **App registrations → New registration**, name it (e.g. `dokploy`) and register it with the defaults — no redirect URI needed.
2. Copy the **Application (client) ID** and the **Directory (tenant) ID** from the overview page.
3. Go to **Certificates & secrets → New client secret** and copy the secret **Value** immediately — it is only shown once.

## Grant Access to the Vault

On your Key Vault:

- **RBAC permission model** (recommended): go to **Access control (IAM) → Add role assignment**, pick the **Key Vault Secrets User** role (read-only) and assign it to the `dokploy` app.
- **Access policies model**: add a policy granting the app `Get` and `List` on secrets.

<Callout type="warn">
RBAC role assignments can take a few minutes to propagate. If Test Connection fails with a permission error right after assigning the role, wait a moment and retry.
</Callout>

## Configuration

In **Settings → Secrets → Add Provider**, choose **Azure Key Vault** and fill in:

- **Name**: the identifier used in references, e.g. `azure-kv`.
- **Vault URI**: e.g. `https://my-vault.vault.azure.net`.
- **Tenant ID**: the Directory (tenant) ID.
- **Client ID / Client Secret**: from the App Registration.

Use **Test Connection** to validate everything before saving, then assign the projects/environments where the provider may be used.

## Reference Format

Azure Key Vault secrets are flat values, so references use the secret name directly:

```bash
DB_PASSWORD=${{vault.azure-kv.db-password}}
STRIPE_KEY=${{vault.azure-kv.stripe-key}}
```

<Callout type="info">
Azure secret names only allow letters, digits and dashes — no underscores. Name your secrets accordingly (e.g. `db-password` instead of `DB_PASSWORD`).
</Callout>
Loading
Loading