Skip to main content

​
First launch

After installing sitectl, run:
This opens the interactive , a live dashboard showing your sites and their current state. From here you can connect to an existing site or create a new one. If you prefer to stay in the command line without the dashboard, every operation in the also has a direct command equivalent.

​
Setting up a site

The first thing sitectl needs is a context: a saved record of how to connect to a site and which environment you’re working with, such as local, staging, or production. You can create one through the setup flow, or with sitectl config set-context directly. See Contexts for the full model. Once you have a context, sitectl knows:
  • Where the project files live
  • Whether to connect locally or over
  • Which plugin owns this site (Drupal, ISLE, etc.)

​
Core workflow

The core workflow commands form a natural progression:
1

Validate before you act

Run sitectl validate to confirm the site configuration is consistent before making changes. It checks that the project files are present, the context is wired correctly, and that no components have drifted.
Exits with an error if anything is wrong. Safe to run any time.
2

Apply a configuration choice

Use sitectl set to turn optional features on or off. The command previews risky changes, asks for confirmation when needed, and updates the component-owned project files immediately.
New stacks default to http://localhost. Ingress settings such as TLS mode, domain, trusted proxies, and upload limits are handled by the ingress component.
3

Inspect or repair drift

Use sitectl converge after manual edits or an upstream update to compare the checkout with .libops/site.yaml and repair only components that are out of alignment. sitectl set updates the component files and this durable intent together.
4

Deploy updates

Use sitectl deploy to apply an upstream update: pull the latest code, update container images, and restart services.
5

Confirm the app is running

Run sitectl healthcheck for a basic status check of the running application.
6

Verify site behavior

Use sitectl verify after updates to run healthcheck-style status plus additional checks supplied by the active plugin. Wire this into CI to make sure important site functionality remains intact.

​
Day-to-day operations

Beyond the core workflow, a few commands come up regularly:

​
Targeting a specific environment

Every sitectl command accepts --context to target a specific environment without changing your default:

​
When to use the TUI vs direct commands

The is best for monitoring, setup, and interactive exploration. Direct commands are better for one-off operations, automation, and scripting. Both modes work against the same contexts and share all underlying logic.