Glossary
Add-on
Section titled “Add-on”A managed service attached to an app — PostgreSQL, Valkey, ClickHouse, Redpanda, object storage, or one of the observability services (logs, metrics, traces). See Add-ons Overview.
A prefix applied to an add-on’s exported env vars when the same kind of service is attached to an app more than once. watasu addons:attach reporting-db --as REPORTING makes DATABASE_URL from that add-on show up as REPORTING_DATABASE_URL.
The deployable unit on Watasu. Owns its source, builds, releases, configuration, processes, attached add-ons, and domains. See Core Concepts → App.
App trust
Section titled “App trust”The mechanism that lets one app reach another app’s private TCP services. See Private Networking.
The process of turning source code into a container image. Watasu uses your Dockerfile if present, otherwise Cloud Native Buildpacks. See Deploy an App.
Buildpack
Section titled “Buildpack”A standardized way to build container images from source without writing a Dockerfile. Watasu uses Cloud Native Buildpacks.
Config var
Section titled “Config var”An environment variable Watasu injects into your app’s processes. Set with watasu config:set, listed with watasu config. Each var is either plain (any maintainer can read and edit) or secret (only the app owner can read or edit; maintainers see the key with a redacted value). Either way, the real value is injected into your processes at runtime. See Configuration.
Domain
Section titled “Domain”A public hostname pointing at a public web process. Watasu manages TLS automatically. See Custom Domains.
Follower
Section titled “Follower”A streaming read replica of a PostgreSQL database. Useful for offloading reporting queries. See PostgreSQL → Followers.
Formation
Section titled “Formation”The set of process types, replica counts, and pod sizes for an app. Inspect with watasu pods, change with watasu pods:scale and watasu pods:type. See Processes and Scaling.
Grafana
Section titled “Grafana”The observability UI for an app — dashboards, log search, metrics queries, trace inspection, alerts. Created automatically the first time you attach a logs, metrics, or traces add-on. See Observability Overview.
The Model Context Protocol — how AI assistants connect to Watasu for read-only visibility into apps, builds, and add-ons. Hosted at mcp.watasu.io. See Connect AI Assistants.
Pipeline
Section titled “Pipeline”A grouping of apps representing stages of the same product (staging, production) with promotion between them. See Pipelines and Promotions.
A tier of an add-on, identified by a slug like postgresql:standard-0. Plans differ on size, durability, replication, and backup behavior. See Add-on Plans.
One running instance of a process. The app’s formation determines how many pods exist for each process type and how big each one is.
Pod size
Section titled “Pod size”The CPU and memory shape assigned to each pod. Ranges from hobby to standard-16x. See Pod Sizes.
Procfile
Section titled “Procfile”A file at the root of your repo that declares process types and the command for each. See Deploy an App → Process types and the Procfile.
Process
Section titled “Process”A named workload inside an app. The name suffix decides routing: web/*-web is publicly routed HTTP, *-tcp is private TCP for microservices, *-rtc is public UDP with a dedicated TURN gateway for WebRTC, release runs once per deploy, anything else is unrouted (typically workers). See Processes and Scaling for the full table.
RTC process
Section titled “RTC process”A process whose name ends in -rtc. Watasu provisions a dedicated TURN gateway, a public UDP port, and per-replica public hostnames, then injects TURN_* env vars into the container. Used for WebRTC SFUs, voice agents, and real-time apps. See Real-Time and WebRTC.
Release process
Section titled “Release process”A process named release (or <group>-release for prefix-scoped gating). Runs once per deploy, before the new release goes live. Use for migrations and one-time per-release setup. A failing release process aborts the deploy. See Processes and Scaling → The release process.
TCP process
Section titled “TCP process”A process whose name ends in -tcp. Reachable as a private TCP endpoint by other apps that explicitly trust this app. Used for internal microservice traffic. See Private Networking.
Promotion
Section titled “Promotion”Copying a release’s image into the next pipeline stage. The image stays the same; the new stage runs it with its own config and add-ons. See Pipelines and Promotions.
Release
Section titled “Release”An immutable snapshot of “what’s live” — image, formation, config vars, attached add-ons. Every deploy and every config change creates a new release. See Logs and Releases.
Review app
Section titled “Review app”A temporary, fully working environment created automatically for a pull request. Requires app.json. See Review Apps.
Sandbox
Section titled “Sandbox”An isolated Linux workspace created from a sandbox template version. Use sandboxes for agent tasks, code execution, file operations, preview ports, and checkpoints. See Sandboxes Overview.
Sandbox resources
Section titled “Sandbox resources”The CPU, memory, network, TTL, and price settings for a sandbox. Root disk size is platform-managed. See Sandboxes Billing.
Sandbox template
Section titled “Sandbox template”A reusable environment definition for sandboxes. Template versions are built artifacts that new sandboxes start from. See Sandbox Templates.
The ownership boundary for apps, add-ons, and sandboxes. Members get access at the level you grant them. See Teams and Access.