Skip to main content
Preview environments are ephemeral environments — copies of your production configuration spun up on demand for a specific purpose (a feature branch, a PR review, a bug repro, a demo). They use the deploy/overlays/ephemeral overlay in your deployment repo, so their configuration comes from the same base as your static environments but with overrides for short-lived usage. The biggest practical difference between a preview environment and a static one: previews don’t count toward your production rollout policies. Readiness checks, label-based deployments, AutoDeploy — features that target static environments — skip previews by default.

​
Preview environments list

Preview Environments list page showing a table of 12 ephemeral environments (preview-20240906t1258, preview-radar, preview-pedro-demo, etc.) with Environment, Namespace, Deployed Services, and Actions columns, and a Setup + Add button in the top-right
Navigate to Environments → Preview in the sidebar to open the list. It only shows environments with the Ephemeral: true flag — static environments never appear here. Each row shows:
  • Environment — the unique identifier (also used as the Kubernetes namespace)
  • Namespace — for preview environments, this is always identical to the environment ID
  • Deployed Services — how many services are currently running in this environment
  • Actions — delete the environment (and optionally its namespace)
Clicking a row opens the same environment deployment page used for static environments, so you can deploy services, view their status, and manage per-env configuration.

​
Creating a preview environment

Click Add in the top-right of the list. Skyhook shows a compact creation form.
New Preview Environment form showing Environment id field pre-filled with a timestamp (preview-20260305t1258), Environment blueprint name, Cluster, and Top domain fields with a Create button

​
Fields

  • Environment id — auto-generated as preview-<timestamp>. You can change it to something descriptive like preview-bug-repro or preview-nadav — it’s used both as the unique ID and the Kubernetes namespace, so keep it DNS-safe.
  • Environment blueprint name — the name Skyhook uses to reference the ephemeral overlay in your deployment repository. Read-only by default and set to the standard deploy/overlays/ephemeral path.
  • Cluster — the target cluster for the new environment. Org defaults are pre-filled from Settings → Preview Environments.
  • Top domain — the ingress domain new services in this environment will use (e.g. preview-bug-repro.dev.example.com). Defaults to the org’s configured preview domain.
Click Create to provision. Skyhook opens a PR against your deployment repo adding the new overlay; ArgoCD applies it once merged.
Ephemeral marker. Environments created from this form are flagged as ephemeral, which is what keeps them in the Preview list, excludes them from production readiness monitoring, and will drive future auto-teardown behavior.

​
Configuration defaults

Preview environments inherit their defaults from Settings → Preview Environments at the org level:
  • Default cluster — the cluster new previews are created on
  • Default top domain — the ingress domain for preview services
  • Blueprint path — the overlay path Skyhook templates new environments from (usually deploy/overlays/ephemeral)
Setting these once means anyone creating a preview from the Add form doesn’t have to pick a cluster or domain every time.

​
Deploying services to a preview environment

Open any preview environment from the list to reach the deployment page. This is the same interface used for static environments:
  1. Pick the services you want to deploy
  2. Choose the image tag / branch for each service
  3. Pick the config branch (defaults to main, but you can point at a feature branch for bundled testing)
  4. Click Review and Deploy
Every service gets environment-specific env vars and secrets from the blueprint, plus any preview-specific overrides you’ve defined for individual services on the service’s Env Vars & Secrets tab.

​
Env vars and secrets for preview environments

Because previews use the ephemeral overlay, they inherit the base env vars defined on each service — but you can still override per-preview-environment. Two patterns:
  • Blueprint templates — defined once on the service, applied automatically to every new preview environment
  • Environment-specific overrides — set on a specific preview environment after it’s created, visible in the Env Vars & Secrets tab when that environment is selected
Deleting a preview environment cleans up its overrides; nothing leaks into the next preview.

​
Deleting preview environments

Click the trash icon on any row in the preview environments list. Skyhook opens a PR removing the overlay from the deployment repo; ArgoCD prunes the namespace and all resources on sync. Ephemeral namespaces are deleted along with the environment — there’s no risk of leaving an orphaned namespace behind (unlike static environments, which preserve their namespace on removal).

​
Troubleshooting

The most common cause is a missing or broken deploy/overlays/ephemeral overlay in your deployment repository. Open the cluster’s ArgoCD UI from the Addons page and check the application’s sync status. You can also review the pull request Skyhook opened to see the generated manifests before merging.
The list filters to ephemeral environments only. If a static environment is showing here, it was likely created via the API or an older version of Skyhook without the ephemeral marker. Delete and recreate it via the Add form to get it properly marked.
Automatic teardown of stale preview environments is on the roadmap. For now, use a scheduled workflow to delete previews older than a certain age with zero deployed services.

​
Further Reading