Analyzes a project and returns structured JSON describing every deployable service: language, version, framework, package manager, install/build/start/dev commands, env vars, and monorepo structure.
$ launch ./my-app
{
"services": [
{
"name": "api",
"dir": "apps/api",
"runtimes": [
{
"language": "typescript",
"name": "node",
"version": "20.11.1",
"version_source": ".nvmrc",
"package_manager": { "name": "pnpm" },
"framework": "next",
"install": "pnpm install",
"build": "next build",
"start": "next start",
"dev": "next dev"
}
],
"env": [
{ "key": "DATABASE_URL" },
{ "key": "PORT", "default": "3000" }
],
"detected_by": ["apps/api/package.json"]
},
{
"name": "worker",
"dir": "apps/worker",
"runtimes": [{ "language": "python", "name": "python", "version": "3.12" }],
"dockerfile": "apps/worker/Dockerfile",
"oci_stages": [
{ "name": "build", "manager": "apt", "distro": "bookworm", "packages": ["build-essential"] },
{ "manager": "apk", "distro": "alpine", "packages": ["libpq-dev"] }
],
"system_deps": ["libpq-dev"],
"detected_by": ["apps/worker/Dockerfile"]
}
]
}
Multi-language directories (Rails + React, Django + React, Laravel + Vue) produce a single service with multiple runtimes — the backend runtime first, the JS/TS runtime second.
cargo install beyond-launch
launch [PATH] [--format json|json-pretty]
| Argument | Default | Description |
|---|---|---|
PATH |
. |
Repository root |
--format |
json-pretty |
json for compact output |
use launch::{discover_local, discover_with_fs, MemoryFs};
// Real filesystem
let discovery = launch::discover_local(Path::new("./my-app"))?;
// In-memory (tests)
let fs = MemoryFs::new(&[
("package.json", r#"{"scripts":{"start":"node server.js"}}"#),
(".nvmrc", "20.11.1"),
]);
let discovery = launch::discover_with_fs(Path::new("."), signals, &fs)?;Service signals — emit named, deployable services:
| Signal | Files |
|---|---|
| Fly | fly.toml |
| Vercel | vercel.json |
| Netlify | netlify.toml |
| Heroku | Procfile |
| Railway | railway.json, railway.toml |
| Dockerfile / Containerfile | Dockerfile, Dockerfile.*, *.Dockerfile, Containerfile variants — all OCI stages with per-stage OS detection and RUN package extraction |
| Docker Compose | docker-compose.yml, compose.yml |
Context signals — describe language, commands, and env vars at a directory:
| Signal | Files |
|---|---|
| Package | package.json, go.mod, Cargo.toml, pyproject.toml, mix.exs, Gemfile, composer.json, pom.xml |
| Framework | next.config.*, astro.config.*, and 30+ others |
| DotEnv | .env, .env.* |
| StructuredConfig | Zod schemas, Pydantic models, Go struct tags |
| LibraryCalls | process.env.X, os.Getenv("X"), etc. |
A directory with a start command but no service signal is promoted to a service automatically. That's the common case: a plain project with package.json scripts.
Two distinct package fields appear on Dockerfile services:
| Field | Source | Format | Meaning |
|---|---|---|---|
system_deps |
Language signals | apt-canonical | Inferred from app dependencies (pg gem → libpq-dev) |
oci_stages[].packages |
Dockerfile signal | raw as written | Declared in RUN apt-get install / apk add / etc. |
oci_stages covers all FROM blocks — build stages and runtime stages — each with its detected OS (manager + distro) and installed packages.
Languages: JavaScript, TypeScript, Python, Go, Rust, Ruby, PHP, Java/Kotlin, Elixir.
use launch::{Signal, SignalOutput, FileSystem, DirEntry};
use std::path::Path;
struct MySignal { paths: Vec<PathBuf> }
impl Signal for MySignal {
fn name(&self) -> &'static str { "my-signal" }
fn observe(&mut self, dir: &Path, entry: &DirEntry) {
if entry.name == "my.config" {
self.paths.push(dir.join(&entry.name));
}
}
fn generate(&mut self, fs: &dyn FileSystem) -> Result<SignalOutput, LaunchError> {
// read self.paths, return services/context/monorepo
Ok(SignalOutput::default())
}
}
let mut signals = launch::signals::default_signals();
signals.push(Box::new(MySignal { paths: vec![] }));
let discovery = launch::discover_with_fs(root, signals, &fs)?;See ARCHITECTURE.md.