Babylon
Babylon is the official command-line interface for provisioning, configuring, and managing Cosmo Tech solutions and platforms. It provides a unified babylon command that abstracts the Cosmo Tech API, Azure resources, and BI tooling such as Superset and Power BI.
With Babylon, you can scaffold, deploy, configure, and tear down environments through a consistent CLI workflow without maintaining custom scripts or managing each underlying service independently.
Installation
Babylon requires Python 3.12+. Installing it inside a virtual environment is strongly recommended.
Using uv (recommended)
If you don't have uv installed yet, follow the
official instructions.
uv venv
source .venv/bin/activate
uv pip install .
Using pip
python -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install .
Development install
Install Babylon in editable mode with the development dependency group (ruff, pytest):
uv pip install -e . --group dev
Verify the installation:
babylon --version
Quick Start
# 1. Point Babylon at a context/tenant so it knows where to store state
babylon namespace use -c my-project -t my-tenant
# 2. Scaffold a new project (cloud provider + BI provider)
babylon init azure superset
# 3. Fill in project/variables.yaml with your environment values, then deploy
babylon apply project/
# 4. Inspect the deployed resources through the API
babylon api organizations get --oid <organization_id>
Usage
Every Babylon invocation follows the same pattern:
babylon [GLOBAL OPTIONS] <COMMAND> [SUBCOMMAND] [ARGS] [OPTIONS]
Global options
| Option | Description |
|---|---|
-v, --verbosity |
Set the logging verbosity (e.g. DEBUG, INFO, WARNING). |
-n, --dry-run |
Run commands in dry-run mode without applying changes. |
--log-path PATH |
Directory where babylon.log is written (defaults to the current directory). |
--kube-context TEXT |
Use a specific kubeconfig context instead of the current one. |
--version |
Print the installed Babylon version and exit. |
--help |
Show help for any command or subcommand. |
Discover any command's options at any time:
babylon --help
babylon apply --help
babylon api organizations --help
CLI Commands
Babylon's commands are organized into two layers: high-level macros that orchestrate common workflows, and a lower-level API command tree for granular control.
Macros
| Command | Description |
|---|---|
babylon init <cloud_provider> <bi_provider> |
Scaffold a new project structure (YAML manifests, variables file, dashboard folders, Terraform web app module). |
babylon apply <deploy_dir> |
Deploy organizations, solutions, workspaces, and web apps described in <deploy_dir>. |
babylon destroy |
Tear down the resources tracked in the current state (requires confirmation, or -y). |
babylon namespace use |
Switch to (or create) a context/tenant namespace used to isolate project state. |
babylon namespace get-contexts |
Show the currently active context and tenant. |
babylon namespace get-all-states |
List local and remote state files available for the current namespace. |
babylon namespace show-states |
Show the details of a local or remote state file for the current namespace. |
API
The babylon api group exposes the underlying Cosmo Tech API resources directly:
| Command | Description |
|---|---|
babylon api organizations |
Manage organizations (create, get, update, delete). |
babylon api solutions |
Manage solutions. |
babylon api workspaces |
Manage workspaces. |
babylon api datasets |
Manage datasets. |
babylon api runners |
Manage runners. |
babylon api runs |
Manage scenario runs. |
babylon api about |
Retrieve API version and metadata information. |
Dashboards
| Command | Description |
|---|---|
babylon superset delete-assets |
Delete dashboard assets from a Superset instance. |
Run
babylon <group> --helpto list every subcommand and its options — for examplebabylon api organizations --help.
Examples
Create and deploy a full project from scratch:
babylon namespace use -c demo -t sandbox
babylon init azure superset
# edit project/variables.yaml with your resource values
babylon apply project/
Deploy only the workspace, skipping the organization and solution:
babylon apply --include workspace project/
Deploy everything except the web app:
babylon apply --exclude webapp project/
Tear down a deployment without the confirmation prompt:
babylon destroy --yes
Get machine-readable output from an API command:
babylon api workspaces get --oid <organization_id> --wid <workspace_id> -o json
Run any command in dry-run mode to preview its effect:
babylon --dry-run apply project/
Configuration
Babylon stores per-project settings in a variables.yaml file (generated by babylon init) and
tracks deployment state under a local namespace defined by babylon namespace use -c <context> -t <tenant>.
variables.yaml: resource-specific values (organization name, solution version, cloud provider settings, etc.) used to render the YAML manifests duringapply.- State files: one state file per context/tenant, listed with
babylon namespace get-all-statesand inspected withbabylon namespace get-contexts. - Logs: every run is logged to
babylon.login the directory given by--log-path(defaults to the current working directory).
Development
Contributions are welcome! A detailed contribution guide is available in the project documentation.
git clone git@github.com:Cosmo-Tech/Babylon.git
cd Babylon
uv venv
source .venv/bin/activate
uv pip install -e . --group dev
Run the test suite and linter before opening a pull request:
pytest
ruff check .
Release Process
To publish a new release:
- Ensure all planned features are merged into
main(JIRA board). - Verify that:
- CI tests are green ➜ GitHub Actions
- The quality gate passes ➜ SonarQube
- Dependencies are up to date (
uv lock --upgrade) - There are no critical vulnerabilities ➜ Dependency-Track
- Bump the version in
Babylon/version.pyfollowing SemVer. - Regenerate the lock file:
uv lock. - Tag the release:
git tag -a -m "5.4.0" 5.4.0. - Push the tag:
git push origin tag 5.4.0. - Write and publish release notes on GitHub Releases.
License
Babylon is released under the MIT License.
Metadata
Release files for cosmotech-babylon-cli 5.5.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| cosmotech_babylon_cli-5.5.2.tar.gz | 396.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| cosmotech_babylon_cli-5.5.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 546.3 kB
Release files / cosmotech_babylon_cli-5.5.2.tar.gz
| Download URL | cosmotech_babylon_cli-5.5.2.tar.gz |
|---|---|
| Size | 396.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
12e9b9e4f5bbd77eb947ddfd7cd1547c87ab107b9e399bff9db57326b9b02335
|
|
BLAKE2b-256 checksum How to use checksums |
72afe6cd4480bca6a894734ef584356c24c7b605bd84eb0c1539448041c5c3ae
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.
Transparency logRelease files / cosmotech_babylon_cli-5.5.2-py3-none-any.whl
| Download URL | cosmotech_babylon_cli-5.5.2-py3-none-any.whl |
|---|---|
| Size | 149.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e4e292040c30682d33b136e86cb460473b0067b4afa4bd0d3a49f9181ffac5b7
|
|
BLAKE2b-256 checksum How to use checksums |
8d5797e4c6c3b3a6caba22cb3b8ee8ff8d901014690c343755d21783ff0cda2e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.
Transparency log