Time Sensitive Environments

When creating or configuring an environment in Facets, you can select an Environment Type that defines the lifecycle behaviour of the environment. This setting determines how long the environment runs, how it manages availability, and how resources are allocated over time.

Available Environment Types

Regular Environments

A Regular Environment is a persistent, always-on environment with no scheduled start or stop behaviour. Once launched, it remains active until explicitly destroyed.

When to use:

• Production environments that must be available 24/7
• Staging or pre-production environments with unpredictable access patterns
• Any environment where downtime is not acceptable

Time-Sensitive Environments

A Time Sensitive Environment operates on a defined availability schedule. Facets automatically manages the environment's active state - scaling it up during working hours and scaling it down (or destroying it) during off-hours.

When to use

• Development and QA environments used only during business hours
• Environments shared across teams in a specific timezone
• Cost optimisation for non-production infrastructure that does not need to run overnight or on weekends

When this type is selected, you must configure an Availability Schedule.

How to Configure Time Sensitive Environments

Short Lived Environment

A Short Lived Environment has a fixed lifespan. Once launched, it runs for a specified duration and is then automatically destroyed — no manual intervention required.

When to use

• Feature branch environments tied to a pull request lifecycle
• Ephemeral test environments for CI/CD pipelines
• Demo or sandbox environments provisioned for a specific event or review session

Availability Rule Type

Defines what happens to the environment when it goes out of its active window.

Scale Up / Scale Down (Recommended for cost optimization): Scales down Kubernetes Deployments and StatefulSets to zero replicas, and disables CronJobs during the inactive period. The cluster and its underlying infrastructure resources remain intact.

• Active period: Resources are scaled up to their configured replica counts
• Inactive period: Deployments and StatefulSets scaled to 0; CronJobs disabled
• Infrastructure: Cluster nodes and cloud resources are retained
• Recovery time: Fast-workloads resume quickly on scale-up
• Use this when you want to save compute costs while keeping the cluster itself alive, ensuring faster recovery at the start of the next active window.

Launch / Destroy: Completely destroys the cluster and all dependent infrastructure resources during the inactive period, and re-provisions them at the start of the next active window.

• Active period: Full cluster and resources are provisioned and running
• Inactive period: Cluster and all dependent infra resources are deleted
• Infrastructure: Fully torn down and rebuilt on each cycle
• Recovery time: Slower — full Terraform provisioning runs on each launch
• Use this for maximum cost savings where recovery time is acceptable. Note that stateful data (e.g., databases not backed externally) may be lost on each destroy cycle unless persistence is explicitly configured.