# Cloud Run previews singleton instances for continuously running workloads > Cloud Run instances enter preview with a dedicated singleton runtime and stable HTTPS endpoint, adding an option for small persistent workers. Canonical URL: https://www.devobs.io/news/news-google-cloud-cloud-run-singleton-instances/ By: Elias Brooks Published: 2026-09-06T11:58:54.635Z Updated: 2026-09-06T11:58:54.635Z Event date: 2026-08-28 Section: Cloud Google Cloud introduced Cloud Run instances in preview on August 28, adding a singleton compute option for continuously running workloads. The [announcement](https://cloud.google.com/blog/products/serverless/introducing-cloud-run-instances) describes one instance without autoscaling, a stable HTTPS endpoint across updates and restarts, and continuous runtime of up to seven days with an automatic restart policy configured by default. ## A new option between request handling and a VM The launch targets workloads such as personal agents that expect one active process instead of a fleet driven by incoming web requests. Its important distinction is execution lifetime and instance count, rather than a new application framework. For engineers, singleton placement can simplify a small worker that polls for work or maintains a connection. It also creates an explicit availability question: what should users or upstream systems observe while that single process restarts? The runtime’s continuity should not be confused with durable application state. A process that survives idle periods still needs a recovery contract for deployment changes, crashes, and scheduled restarts. ## Design the restart before deployment Start by identifying state held only in memory: pending tool calls, cursors, local caches, and unacknowledged messages. Decide which values can be reconstructed and which must be recorded before an external action occurs. A practical acceptance test is to restart the instance midway through a task and verify that it resumes or fails visibly without repeating a completed side effect. A stable endpoint helps callers find the service, but does not establish that an interrupted operation succeeded. This option is most interesting for modest, continuously active workloads whose owners value managed deployment. Teams expecting parallel capacity or high availability should evaluate those requirements separately rather than assuming the singleton primitive will scale into a service fleet. ## Source references -