Applications and environments

An application describes what DeployCrate should deploy. Environments describe where and how that application should run.

Think of the application as the shared definition: name, source, packaging, and default deployment behavior. Think of each environment as a runnable copy of that application with its own domains, server targets, ports, rollout policy, and secrets.

Application and environments overview placeholder — Placeholder screenshot: application with staging and production environments.

Application definition

When you create an application, choose its name, default deployment strategy, packaging type, source provider, and source reference. DeployCrate uses that information to resolve releases and create deployable artifacts.

The default deployment strategy is copied into the environments created by the wizard. You can still tune staging and production independently afterward. For example, staging can use a simpler immediate deployment while production uses blue/green.

Application definition placeholder — Placeholder screenshot: application definition and source selection.

Packaging

DeployCrate supports two packaging styles.

Packaging	Use when
Binary artifacts	You publish a compiled executable, for example from GitHub Releases or a direct URL.
Docker images	You publish an OCI image to Docker Hub, GHCR, or another public source.

Sources

Binary applications can use GitHub Releases or a direct URL. Docker applications can use Docker Hub, GHCR, or a public image source.

For private sources, create the matching credential first. DeployCrate uses the credential to resolve the release asset or registry access token at deploy time.

Environments

The application wizard automatically creates two environments for every new application:

Environment	Intended use
Staging	Validate a release before it reaches users. Use it for smoke tests, domain and secret checks, and source credential verification.
Production	Serve real traffic. Keep production secrets, domains, rollout behavior, and server targets separate from staging.

Each environment can have:

server targets
domains
deployment strategy
application ports
environment secrets
deployment endpoint secret

Staging and production are separate records, not labels on the same runtime. A deployment to staging does not automatically deploy to production. Promote intentionally by creating or selecting the release you already verified, then deploying it to production.

Environment configuration placeholder — Placeholder screenshot: staging and production environment tabs.

Targets

A target connects an environment to a managed server. A deployment cannot run until the environment has at least one target.

Targets are environment-specific. You can point staging and production at the same server for a small project, or separate them onto different servers when you want stronger isolation. When an environment has multiple targets, the rollout strategy controls how DeployCrate applies a release across those targets.

Environment lifecycle actions

Each environment can be started, stopped, or restarted from DeployCrate. These actions are environment-level operations, so DeployCrate applies them to every server target attached to that environment.

Use Stop when you want the environment offline without deleting its configuration, domains, secrets, or release history. Use Start to bring the current deployed version back online across the environment's targets. Use Restart when you need to recycle the running process or container on every target, for example after a transient runtime issue or when checking that the application starts cleanly.

These actions do not change the selected release or create a new deployment. They operate on the currently deployed version for that environment.

Environment lifecycle actions placeholder — Placeholder screenshot: start, stop, and restart actions for an environment.

Deployment strategies

Deployment strategy controls how a single target switches from the current version to the next version.

Strategy	How it works	Use when
Immediate	DeployCrate replaces the running process or container for the target directly.	You want the simplest path, can tolerate a short restart window, or are deploying to staging.
Blue/Green	DeployCrate starts the new version beside the current one, verifies it, then switches traffic to the new slot.	You want zero-downtime production deploys and a clear rollback path.

For binary blue/green deployments, your application must listen on the PORT environment variable supplied by DeployCrate. The blue and green slots need different ports so both versions can run at the same time. For Docker blue/green deployments, DeployCrate maps host ports to the container application port as part of the deployment.

Rollout strategies

Rollout strategy controls how a deployment moves across the environment's server targets.

Strategy	Status	How it behaves
All at once	Available	DeployCrate applies the selected release to every server target in the environment in one deployment operation.
Rolling	Coming soon	DeployCrate will apply the release target by target so part of the environment can stay on the previous version while the rollout advances.

Deployment strategy and rollout strategy solve different problems. Deployment strategy is about version switching on one server. Rollout strategy is about how many servers receive that switch at the same time.

Deployment and rollout strategy placeholder — Placeholder screenshot: deployment strategy and rollout strategy controls.

Ports

For binary applications, the application port is the host port. For Docker applications, DeployCrate allocates host ports from its managed range and maps them to the application port.

For immediate binary deployments, a fixed application port is enough. For blue/green binary deployments, configure separate blue and green ports and make the application read PORT at startup. If the binary always binds to a hardcoded port, DeployCrate cannot run both slots during a blue/green switch.

For Docker deployments, set the port your container listens on. DeployCrate handles the host-side port assignment and Caddy routing.

Secrets

Environment secrets are encrypted and scoped to one environment. Secret changes require a new deployment before the running application sees the updated value.

Use different values for staging and production. Common examples are DATABASE_URL, API keys, OAuth client secrets, feature flags, and third-party webhook secrets. Bulk add accepts one KEY=value pair per line, which is useful when copying values from an existing .env file.

Domains

Add the domain that should route to each environment. The server's Caddy configuration handles TLS and reverse proxying for managed application traffic.

The environment domain does not update DNS automatically. After choosing a domain, create an A record in your DNS provider that points the hostname to the server IPv4 address. Once DNS resolves, Caddy can issue certificates and route traffic for that environment.