Components and Deployments

Everything you run on the platform is managed through the same three-level
model in SVIEW, and once you know it the interface stops needing explanation.
This article covers that model and the day-to-day workflow for application
deployment Components.

The model: Environment, Service, Component

An Environment is one deployment target — production, staging, or
development. It maps to a cluster and its supporting cloud infrastructure.
A Service is a grouping inside an Environment. It holds the parts that
belong together, typically one application and the resources it depends on.
A Component is a single resource: an application deployment, a database, a
cache, a queue, a storage bucket, a scheduled job. Components are where all
configuration lives.

So a database and the application that reads it are two Components in the same
Service, inside one Environment. The same Service usually exists once per
Environment.

Finding your deployment

Open the Environment your application runs in.
Open the Service that contains it.
Click the application Component to open its dashboard.

The dashboard shows the Component's current configuration, status, variables,
and secrets.

Changing a component's configuration

Open the Component dashboard.
Edit the configuration — values, variables, resource limits, and whatever
else applies to that Component type.
Click Save. The platform applies the change automatically.

Watch the status after saving rather than assuming the change landed. A save is
a deployment.

Creating a new Component

New Components come from the Catalog:

Open the Service where the Component belongs.
Click Add Component, or open the Catalog from the sidebar.
Browse by category — Databases, Streaming, Storage, AWS and GCP services, or
Environments.
Select the type, fill in the configuration, and save.

The platform provisions it and it appears in your Service.

Cloning a Component

To copy a Component's configuration into another Environment or Service —
promoting a staging setup to production, for example:

Open the Component you want to clone.
Select Clone from the actions menu.
Choose the target Environment, Service, and namespace.
Override any configuration values that differ in the target.
Save.

Cloning copies configuration only. It does not copy data, persistent storage, or
any runtime state.

Deleting a Component

Open the Component.
Select Delete from the actions menu and confirm.

Deletion is irreversible. Persistent storage attached to a Component is not
removed automatically — raise a request if you need storage cleaned up.

When a save fails or a Component shows degraded

A Degraded state means the Component is deployed but not healthy. The reason
is shown on the Component dashboard itself, so read the status indicator before
raising anything.

Read the reason on the dashboard. A rejected configuration value or a failed
deployment is usually named there directly.
Check the Component's Logs tab. If the configuration applied but the
application will not start, the cause is in the log output — see
Workload Management
for the common failure states and what they mean.
If the change you just made caused it, revert that change and save again to
get back to a known-good state.
If the dashboard reason is not actionable from your side, raise a request
with the Environment, Service, Component name, what you changed, and the
status message shown.