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.

Audit logs provide a complete, tamper-evident record of every action taken inside your Dokploy instance. Every time a user creates a project, deploys an application, updates server settings, adds a domain, or even logs in or out, an entry is written to the audit log with the actor’s identity, what they did, and when they did it. This makes it straightforward to answer questions like “who deleted the production database?” or “which user changed the Traefik configuration last Tuesday?” — essential for compliance audits, security investigations, and operational debugging.

​
Requirements

Access to the audit log API is protected by two independent checks:
  • The caller must have the auditLog: read permission (granted to owner and admin roles by default, and configurable on custom roles).
  • The active organization must have a valid Dokploy Enterprise license. Requests from unlicensed organizations receive a FORBIDDEN error with the message "Valid enterprise license required".

​
What Is Logged

Audit entries are written automatically by the server whenever a mutating operation completes successfully. The following action types are tracked:
ActionDescription
createA new resource was created.
updateAn existing resource was modified.
deleteA resource was deleted.
deployA service or application was deployed.
redeployA service was redeployed (e.g. forced rebuild).
cancelAn in-progress deployment was cancelled.
loginA user authenticated to the instance.
logoutA user session ended.
restoreA backup was restored.
runA one-off command or job was executed.
start / stop / reload / rebuildLifecycle operations on services or servers.
moveA resource was moved between projects.
The full set of auditable resource types is: project · service · application · compose · environment · deployment · previewDeployment · domain · redirect · port · security · certificate · registry · server · sshKey · gitProvider · notification · settings · session · user · customRole · destination · schedule · backup · volumeBackup · docker · swarm · cluster · mount · organization

​
Accessing Audit Logs

1

Navigate to Audit Logs

In the Dokploy dashboard, go to Settings → Audit Logs. The page lists the most recent entries in descending chronological order.
2

Apply filters

Use the filter controls to narrow results by user, date range, action type, or resource type. All filter parameters are optional and can be combined freely.
3

Paginate through results

Audit logs support offset-based pagination. The API returns up to 500 entries per request (default 50). Use the offset parameter to page through large result sets.

​
Querying Audit Logs — auditLog.all

The auditLog.all query accepts the following input and returns { logs, total } — an array of log entries and the total matching count for pagination: 
const { logs, total } = await trpc.auditLog.all.query({
  // --- Filters (all optional) ---
  userId:       "user_01abc",          // filter by actor user ID
  userEmail:    "alice@example.com",   // filter by actor email (partial match)
  resourceName: "my-app",              // filter by resource name
  action:       "deploy",              // one of the action enum values
  resourceType: "service",             // one of the resource type enum values
  from:         new Date("2024-01-01"),// start of date range (inclusive)
  to:           new Date("2024-01-31"),// end of date range (inclusive)

  // --- Pagination ---
  limit:  50,   // 1–500, default 50
  offset: 0,    // default 0
});
Permitted values for the action filter (as exposed by the API): create, update, delete, deploy, cancel, redeploy, login, logout. Permitted values for the resourceType filter: project, service, environment, deployment, user, customRole, domain, certificate, registry, server, sshKey, gitProvider, notification, settings, session.

​
Audit Log Entry Fields

Each entry in the logs array returned by auditLog.all has the following shape: 
{
  "id": "ax7kLmNpQrStUv",
  "organizationId": "org_01xyz",
  "userId": "user_01abc",
  "userEmail": "alice@example.com",
  "userRole": "admin",
  "action": "deploy",
  "resourceType": "service",
  "resourceId": "svc_01def",
  "resourceName": "api-server",
  "metadata": "{\"triggeredBy\":\"manual\",\"commitSha\":\"a1b2c3d\"}",
  "createdAt": "2024-06-15T14:32:10.000Z"
}
FieldTypeDescription
idstringUnique identifier for this log entry (nanoid).
organizationIdstring | nullThe organization in which the action occurred. null if the organization was subsequently deleted.
userIdstring | nullThe user who performed the action. null if the user was subsequently deleted (the userEmail field still preserves the original address).
userEmailstringEmail address of the actor at the time of the action. Always populated even if the user no longer exists.
userRolestringRole of the actor at the time of the action (e.g. owner, admin, member, or a custom role name).
actionstringThe action that was performed (see action table above).
resourceTypestringCategory of the affected resource (e.g. service, domain, server).
resourceIdstring | nullIdentifier of the specific resource. May be null for actions that do not target a specific record.
resourceNamestring | nullHuman-readable name of the resource at the time of the action.
metadatastring | nullJSON-encoded object with additional context, such as triggered-by information, configuration snapshots, or request details.
createdAttimestampISO 8601 timestamp of when the action occurred. Indexed for efficient date-range filtering.
All filter parameters to auditLog.all are optional and combinable. Common patterns: 
// All deploys in the last 7 days
const { logs: recentDeploys } = await trpc.auditLog.all.query({
  action: "deploy",
  from: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000),
});

// All changes made by a specific user
const { logs: userLogs } = await trpc.auditLog.all.query({
  userId: "user_01abc",
  limit: 100,
});

// All delete actions on servers
const { logs: serverDeletes } = await trpc.auditLog.all.query({
  action: "delete",
  resourceType: "server",
});

// All audit events for a named service
const { logs: serviceLogs } = await trpc.auditLog.all.query({
  resourceName: "api-server",
  resourceType: "service",
});
The from and to parameters accept JavaScript Date objects or ISO 8601 strings (the Zod schema coerces either). The date filter is applied to the createdAt column, which is indexed for performance.

​
Log Retention

Dokploy does not automatically prune audit log entries. Retention is governed by the storage capacity of your Dokploy instance’s PostgreSQL database. For long-running installations, consider:
  • Scheduling a periodic export and archival of old log records.
  • Configuring PostgreSQL table partitioning or time-based retention policies at the database level.
  • Monitoring database disk usage via the Monitoring panel in Dokploy.

​
Exporting Logs

The auditLog.all endpoint supports pagination up to 500 records per request, which can be used to programmatically export logs to an external SIEM, logging platform, or CSV file. Iterate through pages using offset until fewer records than limit are returned: 
const PAGE_SIZE = 500;
let offset = 0;
const allLogs = [];

while (true) {
  const page = await trpc.auditLog.all.query({ limit: PAGE_SIZE, offset });
  allLogs.push(...page.logs);
  if (page.logs.length < PAGE_SIZE) break;
  offset += PAGE_SIZE;
}
Combine audit logs with Dokploy Notifications for real-time security monitoring. For example, configure a Slack or Discord notification for deployment events and use audit logs to maintain the historical record. This gives you both immediate alerts and a full trail for after-the-fact investigations.
Audit log entries are read-only. There is no API procedure to modify or delete individual log entries. The userId and organizationId foreign keys use SET NULL on delete, so entries are preserved even when a user or organization is removed — the userEmail and userRole fields ensure the actor is always identifiable.

Build docs developers (and LLMs) love

Get started for freeTalk to us