Resources, builds & Advanced settings

Resource types

Upstand groups deployable workloads into three resource types:

• Applications build from GitHub, GitLab, Bitbucket, Gitea, or a generic Git URL. Docker registry images are also supported.
• Databases deploy PostgreSQL, MySQL, MariaDB, MongoDB, and Redis with persistent named volumes and generated connection metadata.
• Compose resources deploy a raw or repository-provided Compose file as either a standalone Docker Compose project or a Docker Swarm stack. Routes must identify the target service.

Every resource belongs to a project and environment and exposes the same operational tabs: General, Environment, Advanced, Domains, Deployments, Containers, Backups, Logs, and Monitoring. Some tabs are intentionally more useful for a specific resource type; for example, build configuration is application-only and database credentials are shown only to authorized users.

Application resources can enable signed GitHub pull-request previews from the General tab. Configure the maximum active previews, wildcard suffix, HTTPS certificate behavior, and target port. A preview is created for an opened or synchronized pull request and removed when the pull request closes.

When an application uses a separate build server, choose an organization-owned Build registry in General → Execution Infrastructure. Upstand uses that registry for the build-server transfer image and honors its image prefix; if none is selected, the first organization registry remains the compatibility fallback for existing resources.

Application builds

The builder is selected from the resource’s General → Build Configuration card:

• Dockerfile: repository build path, Dockerfile path, context path, optional multi-stage target, JSON Docker build arguments, no-cache builds, and optional builder-cache cleanup.
• Railpack: repository build path and pinned Railpack version.
• Nixpacks: repository build path and optional publish directory for static output.
• Heroku Buildpacks: repository build path and Heroku stack version.
• Paketo Buildpacks: repository build path and Cloud Native Buildpacks builder.
• Static: repository build path, publish directory, and SPA fallback behavior.
• Generated domains: Domains & HTTPS can create an operator-confirmed sslip.io hostname from a routable public IPv4 address; it is still a normal editable Caddy route.

Build settings are validated as a discriminated configuration before they reach the deployment worker. A build setting change affects the next deployment only. Build and runtime environment variables remain separate: build arguments are passed to the image builder, while environment variables are injected into the deployed service.

Dockerfile applications may also define BuildKit secrets as a JSON object of string values. Upstand encrypts this object at rest, passes each key as an ephemeral --secret id=<key>,env=<key> mount, and never returns the stored values in resource responses. Dockerfiles should consume them with RUN --mount=type=secret so secrets do not become image layers.

Docker image applications may select an organization Docker registry. The selected credentials are passed to Docker for private image pulls and Swarm task authentication; registry passwords remain encrypted in the registry record. Applications can separately enable a rollback registry so private images remain pullable when Swarm restores the previous service specification. The rollback registry is organization-validated and its credentials are decrypted only for that request.

Database resources also support an optional external Docker port. Leaving it blank uses the engine default (with the development offset applied by the local runtime). libSQL exposes separate HTTP, gRPC, and admin port fields for its 8080, 5001, and 5000 listeners; configured published ports must be unique. Reload restarts the database service. Rebuild requires an explicit confirmation, removes the managed database volume, redeploys the service with the saved encrypted credentials, and records the operation in deployment history. Export a backup before rebuilding.

The database editor uses the supported engine image list by default. Operators can explicitly enter a custom Docker image when a vendor build or engine variant is required. Custom references are validated for safe Docker-reference characters and opt in at the API boundary; the managed image allowlist remains the default.

Advanced service configuration

Advanced is the common Dokploy-inspired service contract for applications, databases, and Compose resources. It supports:

• command and argument overrides;
• published TCP/UDP ports;
• persistent volume mounts and read-only mounts;
• runtime environment overrides and Docker labels;
• CPU and memory limits/reservations;
• restart condition, delay, window, and retry attempts;
• placement constraints;
• container health checks;
• init process, read-only root filesystem, TTY, and privileged mode.

The UI provides structured controls and a validated JSON editor for the complete contract. Configuration is persisted with the resource and applied by the Swarm service deployment path on the next deploy.

Environments & secrets

Environment variables are managed as key/value pairs. Values are masked by default in the dashboard and are injected into the service at deployment time. Database credentials are encrypted at rest with Upstand’s Secret Box wrapper; never copy database passwords into public image tags or Compose files.

Network model

Non-isolated applications, databases, and Compose services share the attachable upstand-network overlay across projects and environments. This gives Caddy and routed services stable Docker DNS while preserving normal service-to-service connectivity. Compose files may define additional networks; Upstand preserves them and adds a managed ingress network to services that do not use an incompatible network_mode.

When Isolated deployment is enabled, the resource receives a dedicated upstand-resource-<resource-id> overlay. Caddy is attached to that network only while the resource has active routes, and named volumes can be prefixed to prevent collisions between identical Compose projects. Removing a resource removes its managed isolated network after Docker releases its endpoints.

Compose volumes explicitly marked external are never renamed or prefixed; they remain operator-owned shared storage.

Raw Compose resources include a Randomize names action. It appends a collision-safe suffix to service, network, volume, config, and secret names and rewrites their references together. This is useful when importing a Compose file that was already deployed elsewhere. The same behavior can be enabled for deployments through the advanced randomize setting.

Compose templates

The Templates page stores organization-scoped Compose templates with a name, description, tags, and validated YAML. Templates can be searched, edited, deleted, or deployed directly into an environment. Deployment creates a Compose resource and can enable collision-safe randomization so repeated deployments do not reuse service, network, volume, config, or secret names. Template records and source files are isolated by organization permissions.

Operational tabs

• Deployments shows queued, running, successful, and failed runs with their logs.
• Containers lists live Docker containers or Swarm task containers and exposes start, stop, restart, and kill controls when the selected container is reachable from the current Docker node, plus logs/configuration/network/mount views where available.
• Backups schedules and restores database/volume backups to configured S3 destinations. Control-plane and Caddy backups are managed from the Web Server page.
• Logs is a searchable, filterable, pausable live log reviewer.
• Monitoring retains live CPU, memory, and network samples from the Docker runtime.
• Scheduled commands runs validated cron commands inside the resource container and supports immediate enable/disable/delete operations.
• Database lifecycle exposes safe engine-specific Health and Version diagnostics in addition to Reload and confirmed destructive Rebuild. Diagnostics use an allowlisted command per engine; arbitrary shell input is not accepted by that API.