oridecon-cli ships the oridecon command — the day-to-day driver for every Oridecon project. It scaffolds new apps, runs the development server, drives database migrations, manages configuration, and exposes a plugin surface that lets installed extensions contribute their own subcommands.
For the full command reference, see the oridecon-cli package docs.
1. Install & Verify
Section titled “1. Install & Verify”uv add oridecon-cli # recommended# or: pip install oridecon-clioridecon --version # → oridecon <version>oridecon --help # full command listThe CLI is also pulled in transitively by most projects, so uv sync from a generated project is usually enough.
Global flags work on every subcommand:
| Flag | Effect |
|---|---|
--json | machine-readable output where supported |
--quiet, -q | suppress non-essential output |
--debug | print tracebacks on error |
--no-color | disable ANSI colour |
--config, -c | path to application.yaml |
2. Scaffolding a New Project
Section titled “2. Scaffolding a New Project”oridecon new project renders one project tree. Templates pick packages and application.yaml sections — not a different shape:
oridecon new project my-app # default template: web-apioridecon new project my-app --template api # JSON API onlyoridecon new project my-app --template full # web + db + auth + cacheoridecon new project my-app --interactive # prompt for templateoridecon new module auth # bounded context, same tree| Flag | Default | Notes |
|---|---|---|
--template, -t | web-api | one of minimal, api, web-api, graphql, worker, full |
--directory, -d | . | parent directory for the new project |
--interactive, -i | false | prompts for template |
To scaffold a reusable extension package instead of an application:
oridecon new package my-feature # → oridecon-my-feature/ with src/ + provider stuboridecon init writes a minimal application.yaml into an existing directory — useful when adopting Oridecon in a project that already has a pyproject.toml:
oridecon init --full # full config (web/db/auth/cache/monitor sections)oridecon init --minimal # just project + logging (default)oridecon init --force # overwrite an existing application.yamlSee Project Structure for what the templates lay down. Feature types land in domains/ (not models/). App providers land in src/<app>/di/ (*_provider.py). If the generator inventory still says oridecon gen model, the file still belongs in domains/ — this site wins.
3. Running Locally
Section titled “3. Running Locally”Two commands launch your app — pick by intent:
oridecon run # production-shaped: --host 127.0.0.1, --reload onoridecon dev # development server, --reload on, ORI_ENV=developmentBoth auto-detect your entry point (src/main.py, create_app, etc.) using discover_entry_point and pick the best available server backend (prefers granian → uvicorn, falls back to hypercorn).
oridecon run flags:
| Flag | Default | Notes |
|---|---|---|
target (positional) | auto-detected | module:attr, e.g. my_app.app:create_app |
--host, -h | 127.0.0.1 | bind address |
--port, -p | 8000 | bind port |
--reload/--no-reload | true | hot reload |
--workers, -w | 1 | worker processes |
--profile | none | sets ORI_PROFILE for the run |
--server | auto | uvicorn, granian, or hypercorn |
--mcp-port | none | also serve MCP (SSE) on this port |
oridecon dev accepts --entry, --host, --port, --reload/--no-reload, --env, --server. For production, use oridecon dev start (binds 0.0.0.0, no reload, takes --workers) or invoke an ASGI server directly — see Deployment.
4. Database Migrations
Section titled “4. Database Migrations”oridecon db wraps oridecon-sql’s migration runner. The most common flow:
oridecon db init migrations # create migrations/ directoryoridecon db create add_users_table # new empty migration fileoridecon db upgrade # apply pending migrationsoridecon db status # show current version + pendingoridecon db history --limit 20 # last N applied migrationsoridecon db downgrade # roll back the most recentoridecon db downgrade 0003_seed # roll back to a specific versionInspection and maintenance:
oridecon db inspect # list tables + columnsoridecon db inspect --table users # one table's columns + typesoridecon db shell # open psql / mysql / sqlite3 clientoridecon db validate # check applied migrations have filesoridecon db reset --force # drop & re-migrate (SQLite-optimized)oridecon db backup --output dump.sqloridecon db restore dump.sql --forceSeed scripts in seeds/*.py (each exposing a run(provider) function) are applied by oridecon db seed or as part of oridecon db reset --seed.
All db commands read DATABASE_URL from the environment (default sqlite:///./dev.db). When oridecon-sql is installed, the runner is resolved through the DI container so connection pooling and observability hooks are active.
See the Database guide for the repository pattern these migrations support.
5. Inspecting & Diagnosing
Section titled “5. Inspecting & Diagnosing”oridecon list # all available commands, groupedoridecon list --group Databaseoridecon version --all # versions of every installed oridecon-* packageoridecon system info # Python version, platform, config pathoridecon system health # project + contributor health checksoridecon system doctor --fix # diagnostics with auto-fix hintsoridecon system providers # provider sections in application.yamlInstalled extensions register CLI contributors — discover them with:
oridecon contrib list # all contributors + their contributionsoridecon contrib inspect sql # generators/commands/health checks for oneoridecon contrib check # verify every contributor loadsCode generation routes through contributors as well:
oridecon gen list # all discovered generatorsoridecon gen controller users # src/<app>/controllers/…oridecon gen service greetings # src/<app>/services/…oridecon gen provider billing # src/<app>/di/billing_provider.pyoridecon gen error not_found # src/<app>/shared/errors/… (always shared)6. Configuration
Section titled “6. Configuration”The CLI looks for application.yaml in the current directory (and walks up to find one). Override with --config /path/to/app.yaml.
Profiles are environment-driven — set ORI_PROFILE=production and a matching application.production.yaml is overlaid on the base config. Any value can be overridden by a ORI_-prefixed env var with __ for nesting:
export ORI_PROFILE=stagingexport ORI_SQL__BACKEND__URL=postgresql+asyncpg://...Useful config commands:
oridecon config show # current resolved config (secrets masked)oridecon config show --reveal-secrets # unmaskedoridecon config validate # schema + cross-field validationoridecon config doctor --env production # environment-specific diagnosticsoridecon config env # ${VAR} references and whether they're setoridecon config env --missing # exit 1 if any are unsetoridecon config env-example # generate .env.example from configoridecon config diff -c application.production.yamloridecon config schema # dump the JSON schemaSee Configuration and YAML Configuration for the full layering rules.
7. Adding Providers & Shell Completion
Section titled “7. Adding Providers & Shell Completion”oridecon add database # add oridecon-sql + db: section to YAMLoridecon add auth # add oridecon-auth + auth: sectionThe add command edits pyproject.toml (via uv add when available) and patches application.yaml with the provider’s default config block.
Generate shell completion:
oridecon completion --shell bash # also: zsh, fish, powershelleval "$(oridecon completion --shell zsh)"Next Steps
Section titled “Next Steps”- Your First App — the 60-second walkthrough using
oridecon newandoridecon run - Project Structure — where
genandnew modulewrite files - Database & Persistence — the repository pattern these migrations feed
- Deployment & Infrastructure — running
orideconin production - CLI reference — command tree dump
oridecon-clipackage — full flag-by-flag reference and the contributor API