Security Considerations
Launchfile is a trust boundary — like a Dockerfile or Makefile, it declares what should run. Providers that execute Launchfiles should be aware of these security properties:
Config values are untrusted input
The config field in requires/supports entries accepts arbitrary key-value pairs (Record<string, unknown>). Providers MUST validate and sanitize config values before using them in shell commands, SQL queries, API calls, or any other injectable context. For example, a postgres provider should validate that extension names match ^[a-zA-Z_][a-zA-Z0-9_]*$ before passing them to CREATE EXTENSION.
Commands and health checks are executable
commands.start, commands.build, commands.install, commands.dev, commands.release, and health.command contain shell commands that the provider executes — and install/dev run natively on the host in source mode (see Execution modes and source trust). This is by design — the user chose to run this Launchfile. Providers that fetch Launchfiles from remote sources (catalogs, URLs) should display what will be executed and prompt for confirmation before running.
Execution modes and source trust
A Launchfile can be executed in four modes, with different trust requirements. Where the app's code runs determines how much the user must trust the source:
| Mode | What executes where | Appropriate for |
|---|---|---|
| Dev launch from source | install / dev commands run natively on the host, in the project directory |
Repos the user owns or has reviewed — the commands have full user-level access to the machine |
| Containerized build + run | build: runs inside docker build; the app runs inside a container |
Unknown or third-party repos — neither the build nor the app touches the host beyond declared ports and volumes |
| Image run | A pre-built image: is pulled and run in a container |
Catalog apps; trust shifts to the image publisher |
| Cloud build + deploy | Build and run both happen on remote infrastructure | Production; the platform's isolation applies |
Guidance for providers:
- Native (source-mode) providers SHOULD only run local sources. Running
install/devcommands from a freshly fetched URL or catalog entry executes unreviewed code with user privileges. If a native provider supports remote sources at all, it MUST show the commands and prompt. - Container-based providers are the sandboxed path for untrusted sources. A
build:config keeps the entire build insidedocker build— dependency install scripts, codegen, and compilers never execute on the host. Remote build contexts (git URLs) extend this: the provider never even clones the repo onto the host itself. - The confirmation prompt is per-source, not per-field. Before executing a remote Launchfile, show the user what will run: images to pull, components built from source, resources provisioned, and host capabilities requested.
Host capabilities require user consent
host.privileged, host.docker, and host.filesystem — and equivalently the host:-marked capability entries in requires/supports (see Host capabilities) — declare elevated capabilities. Providers should either refuse or require explicit user confirmation before granting these. The required host: marker makes the full privilege surface extractable from the file itself; launchfile validate surfaces it as a host capabilities requested: summary.
Secrets and state
Generated secrets (from generator: secret|uuid) and connection credentials should be stored with restrictive file permissions (e.g., 0600) and excluded from version control.