Landscape Lifecycle

A Landscape is a deployment configuration of your application and its architecture, defined by the ci.yml file. It specifies what services to run, how they connect, and how resources are allocated. Each Landscape instance comes with an associated Workspace—your cockpit for interacting with that specific Landscape. This article walks you through the complete lifecycle of a Landscape, from initial creation to deletion.

Architecture Overview

For a detailed look at how Landscapes and Workspaces work together, see Landscapes & Workspaces.

---

Initial Creation

When you create a new Workspace, it's initially attached to an empty Landscape—no resources besides the Workspace itself are provisioned yet, regardless of whether you're starting fresh or cloning an existing project:

• New projects: Your Landscape is waiting for a ci.yml configuration to define what should be deployed.
• Existing projects: Even if you clone a git repository that already contains a ci.yml, the Landscape resources won't be provisioned until you sync them (see Provisioning Resources).
• Your Workspace can be used to execute build and prepare steps for your application.
• You can use the Cloud IDE to edit files, including the ci.yml, and test changes in real-time.

---

Provisioning Resources

Once you have a ci.yml file defined, syncing the Landscape will provision all the resources specified in your configuration:

• Pods and replicas for your runtime deployments
• Managed services (databases, caches, message queues)
• Virtual machines (if configured)
• Landscape router for networking rules and routing configuration
• Any other resources referenced in the ci.yml

To provision or update your Landscape:

1. Navigate to the Execution Manager in your Workspace.
2. Click the Sync button to apply your ci.yml configuration.

Codesphere will then instantiate all defined resources and connect them through the private network.

tip

Some runtime types support additional lifecycle operations beyond just syncing. See the Runtime Operations section below.

---

Runtime Operations

Certain runtime types (like Codesphere Reactives and Container Runtimes) support more granular control beyond just syncing:

Start, Stop, and Restart

These runtimes allow you to control the execution within the pod without deprovisioning the resources:

• Start: Begin executing your application inside the provisioned pod.
• Stop: Halt execution while keeping the pod and its resources allocated.

These operations are managed through the Execution Manager in your Workspace.

Off-When-Unused

Many runtime types support an off-when-unused config flag:

• Despite being synced, the service monitors activity and automatically shuts down when idle.
• When a URL request or Workspace cockpit request arrives, the service automatically restarts.
• The workspace cockpit itself is deployed exactly this way, ensuring it's always available when you need it but doesn't consume resources when idle.
• This works seamlessly because of the persistent volume attached to each Landscape, preserving your application state.

Ideal use cases for off-when-unused:

• Development environments: Developers only need their environment while actively working in it, not 24/7
• Staging/test environments: Testing happens in bursts, not continuously
• Internal tools and admin panels: Accessed sporadically throughout the day
• Demo environments: Only active during customer demos or trials
• Preview deployments: Feature branch deployments that are checked occasionally

This helps optimize resource consumption while maintaining instant availability when needed.

---

Updating Your Landscape

A Landscape version should always be tied to a specific git state synced to the filesystem. This includes the ci.yml, configuration files, and any code that gets executed.

Development & Testing Updates

During development, you can make direct modifications to the filesystem (actual code changes when working with reactive services or configuration changes like ci.yml for other runtimes):

1. Edit files in the Cloud IDE or terminal.
2. Run the build and prepare steps (if applicable)
3. When ready, Sync the Landscape to apply configuration changes.
4. Stop and Start the runtime execution to apply code changes.

Production Updates

For production Landscapes, updates typically follow this flow:

1. Commit and push changes to your git repository.
2. In the Workspace, run git pull to fetch the latest changes.
3. Sync the Landscape to apply new ci.yml configurations.
4. Stop and Start the pipeline execution for the relevant runtimes.
5. All of these steps can be automated through your CI pipeline, allowing for seamless updates without manual intervention.

Sync Required

The Landscape does not sync automatically when you pull from git. You must explicitly trigger a sync and restart runtime execution to apply updates.

Managing Different Environments

You can use CI Profiles to maintain different configurations for development, staging, and production environments. Each profile creates a separate ci.yml variant (e.g., ci.dev.yml, ci.prod.yml), allowing you to easily switch between environment-specific configurations.

Zero-Downtime Deployments

For production workloads, consider implementing zero-downtime releases by routing traffic between multiple Landscape instances through custom domain configuration.

---

Teardown

You can tear down a Landscape without losing your data:

• All resources are deprovisioned and returned to the instance pool.
• Persistent volumes remain in place, preserving your application state and data.
• The Landscape can be resynced at any time to provision resources again and pick up exactly where it left off.

This is useful for:

• Saving costs on non-production environments during off-hours
• Temporarily freeing up cluster resources
• Pausing a project without losing work

To tear down a Landscape, use the Teardown option in the Execution Manager.

---

Deletion (End of Lifecycle)

When you delete a Landscape via the Workspace cockpit:

• All resources are deprovisioned.
• All persistent volumes are cleared.
• Everything not tracked in git will be lost permanently.

Permanent Data Loss

Deletion is irreversible. Ensure all important code, configurations, and data are committed to your git repository before deleting a Landscape.

Recreation After Deletion

As long as your ci.yml (Infrastructure as Code) contains everything you need:

• You can create a new Workspace.
• Sync the ci.yml from your git repository.
• Spin up a fresh instance with the same configuration.

This demonstrates the power of the declarative approach—your entire infrastructure can be recreated from version-controlled configuration files.

---

Lifecycle Summary

Stage	Description	Data Persistence
Creation	Empty Landscape attached to new Workspace	N/A
Provisioning	Resources allocated based on ci.yml	Volumes created
Running	Services active and serving traffic	Data in volumes
Stopped	Execution halted, resources still allocated	Data in volumes
Teardown	Resources deprovisioned, volumes remain	Data preserved
Deletion	Complete removal including volumes	Data lost