Gitpod preview URL stability limits during application migration

Goal

We are evaluating whether a Gitpod workspace can serve as a cutover environment for a small application migration that must avoid downtime. The plan assumes the application can start from .gitpod.yml tasks and expose a preview port, but the migration requires a stable address that clients can resolve before and after cutover.

Constraints and uncertainty

Gitpod workspaces are ephemeral. Only the /workspace directory persists across restarts; running processes, exposed ports, and preview URLs are lost when a workspace stops or times out. Prebuilds can cache dependencies and build artifacts, but they do not guarantee a warm, load-balanced endpoint. In self-hosted Kubernetes deployments, cluster ingress and services can route traffic, yet that behavior depends on the underlying infrastructure rather than Gitpod's default SaaS workflow.

The unresolved decision is whether dynamically assigned workspace preview URLs can be reliably mapped to a stable external endpoint during a migration, given their tight coupling to workspace lifetime and the lack of built-in high availability.

Questions

1. Can a Gitpod workspace preview URL be treated as a stable ingress target for a zero-downtime migration, or does its dynamic assignment and workspace-bound lifetime make it unsuitable without external orchestration?
2. Do workspace timeouts and inactivity shutdowns introduce unavoidable interruption windows that prevent a seamless cutover, even when /workspace state is preserved?
3. In a self-hosted Kubernetes deployment, can workspace traffic routing be decoupled from the workspace lifecycle so an application remains reachable while the workspace restarts?