Skip to main content

New features

Key last-used tracking

You can now see when each API key was last used for verification. A new lastUsed field is available in the key verification API response, so you can identify stale keys and clean up unused credentials.

Deployment approval for external contributors

Deployments triggered by non-collaborators (such as fork-based pull requests) now require explicit approval from a project member before they proceed. A GitHub Check Run appears on the PR, and you can approve or dismiss the deployment directly from the Unkey dashboard.

Watch paths

You can now configure glob patterns (e.g., src/**, **/*.go) in your deployment settings to control which file changes trigger builds. When no files in a push match your watch paths, the deployment is skipped — and the dashboard shows a dedicated skipped view explaining why.

On-demand deployments

You can now trigger a deployment manually from the dashboard by selecting a branch and commit SHA from your connected repository. This is useful when you need to redeploy without pushing a new commit.

Deployment status on GitHub PRs

Deployment progress is now reported directly to GitHub. You’ll see status updates on your commits via the GitHub Deployments API, and a summary comment is posted to your pull request with a table showing the status of each app and environment.

Stopped status for idle deployments

Deployments that have been scaled down to zero instances now show a Stopped status instead of remaining in their previous state. This happens automatically when a deployment with an idle timeout is spun down because it has no running instances — for example, when the deployment’s desired state is standby or archived. You can filter deployments by the Stopped status in the dashboard to see which deployments are currently idle. Stopped deployments resume automatically when they receive traffic. The STOPPED status is also available in the API response when retrieving deployment details.

Delete projects

You can now delete projects from the dashboard. This removes the project and all associated apps, environments, and deployments.

Runtime environment variables for deployments

Your deployed workloads now have access to a set of automatically injected environment variables that provide context about the running deployment. Use these to add metadata to your logs, identify which instance is handling a request, or gate behavior based on the current environment.
VariableDescription
UNKEY_DEPLOYMENT_IDUnique identifier for the current deployment
UNKEY_ENVIRONMENT_SLUGSlug of the environment (e.g., production, staging)
UNKEY_REGIONRegion where the instance is running
UNKEY_INSTANCE_IDUnique identifier for the specific running instance (pod)
UNKEY_GIT_COMMIT_SHAGit commit SHA that triggered the deployment
UNKEY_GIT_BRANCHGit branch that triggered the deployment
UNKEY_GIT_REPOFull repository name (e.g., org/repo)
UNKEY_GIT_COMMIT_MESSAGECommit message of the deployed commit
Git-related variables are populated automatically when your deployment is connected to a GitHub repository. UNKEY_INSTANCE_ID is unique per running instance, so you can use it to distinguish between replicas.
// Example: structured logging with deployment context
app.use((req, res, next) => {
  console.log(JSON.stringify({
    deployment: process.env.UNKEY_DEPLOYMENT_ID,
    environment: process.env.UNKEY_ENVIRONMENT_SLUG,
    region: process.env.UNKEY_REGION,
    instance: process.env.UNKEY_INSTANCE_ID,
    commit: process.env.UNKEY_GIT_COMMIT_SHA,
    path: req.path,
  }));
  next();
});
The previous UNKEY_WORKSPACE_ID, UNKEY_PROJECT_ID, and UNKEY_ENVIRONMENT_ID variables have been replaced by the new set listed above.

Updates

Improved root keys table

The root keys settings page now uses a paginated, sortable table with keyboard navigation and improved loading states.

Dockerfile path autocomplete

The deployment settings UI now detects Dockerfiles in your connected repository and offers autocomplete suggestions. It also validates paths in real time and suggests corrections for case mismatches.

Friendlier build error messages

When a Docker build fails, the dashboard now shows a human-readable error message instead of raw BuildKit output. Common issues like empty Dockerfiles, missing files, and syntax errors include actionable guidance and a link to settings.

Custom domain prioritization

Custom domains now appear first in the deployment domains list. Verified custom domains take priority over platform-generated domains, making it easier to find your production URLs.

Environment variable improvements

Pasting environment variables now appends to your existing list instead of replacing it. You can also search through your variables by key name, and duplicate key validation now highlights all conflicting rows.

Bug fixes

  • Deployment errors now return specific error codes instead of generic 502 responses.
  • Build and runtime settings (Dockerfile, port, command, healthcheck) now sync across all environments in a project.
  • The workspace switcher dropdown no longer takes up excessive space when you only have one workspace.
  • The CLI now correctly parses flags that appear after positional arguments (e.g., deploy nginx:latest --project=local).
  • Fixed several onboarding flow issues, including a regression where settings were being applied twice.
Last modified on March 24, 2026