Your platform team: a web app, a CLI and an MCP server on one core.
Every new service costs the same week: scaffold, lint config, CI, versioning, deploy pipeline, IAM. Then the next one drifts from the last. Action Platform turns that week into one command — or one click — and keeps every app on the same rails, in your git host and your cloud account.
Three doors, one core:
| Web app | Organizations › projects › apps. Create an app from a template, connect GitHub / GitLab / Bitbucket, cut releases, run deploys — from a browser. One command to self-host. |
| CLI | pipx install action-platform and the same verbs on your machine: init, branch, pr, release, deploy, rollback, diagnose. |
| MCP server | The same operations as tools for Claude Code, Codex, Cursor — locally, or against your hosted platform after action-platform login. |
Self-host in one command
curl -fsSL https://raw.githubusercontent.com/actionplatform/action-platform/master/deploy/install.sh | sudo sh
# with a domain and TLS:
curl -fsSL https://raw.githubusercontent.com/actionplatform/action-platform/master/deploy/install.sh | sudo sh -s -- platform.example.com you@example.com
Installs Docker if needed, generates the secrets, starts Postgres + API + web (+ Traefik with Let's Encrypt when a domain is given) and prints the URL. Open it: first account, first organization, connect a code host — done. Files live in /opt/action-platform; see deploy/ for the compose file and the two Dockerfiles.
Already on Dokploy? Create a Compose service and import deploy/dokploy/template.b64: secrets and domain are generated, Dokploy's Traefik handles TLS. → Self-hosting
Or just the CLI
pipx install action-platform
action-platform init web python fastapi --name "orders" --cloud aws/lambda
Thirty seconds later you have a FastAPI service with tests, lint, CI wired, a SAM template, a least-privilege IAM policy, and a GitHub repo already pushed (--no-push to keep it local).
Why teams pick it
| One command, whole lifecycle | init → release → deploy → rollback → diagnose → destroy. Same verbs for a Python API on Lambda, a Go service in Docker, a React app on Amplify. |
| Templates from production, not tutorials | Every project template is extracted from a real shipping product. Real layout, real CI, real gotchas already fixed. |
| Cloud is a layer, not a fork | Projects stay cloud-agnostic. --cloud aws/lambda overlays deploy files; swap to docker tomorrow with one command. |
| Your CI, your account, your git | Runs on GitHub Actions, GitLab CI or Jenkins you already have. Repositories on GitHub, GitLab, Bitbucket or any git server, connected with OAuth. Infra lands in your AWS account through OIDC — no long-lived keys, no vendor in the loop. |
| Governance that ships with the code | Git-flow and Conventional Commits enforced by git hooks before a commit exists and by CI on every PR; changelog generated; AGENTS.md for humans and AI agents; Trivy scans; least-privilege IAM in requirements/. |
| Fix once, everywhere | CI logic lives in versioned shared repos (ci-scripts, ci-github, ci-gitlab, ci-jenkins). Bump v1, every project picks it up. |
What you get
| Type | Stacks |
|---|---|
web |
python (FastAPI, FastMCP), go (Gin), node (React) |
library |
python, go, php, node, java, rust |
docs |
mkdocs |
plugin |
chrome |
empty |
platform.toml + code quality only |
Cloud overlays aws/lambda, aws/amplify, docker; services postgres (docker, aws-rds). Every template comes with tests, lint, CI and AGENTS.md. → Templates
Git-flow, enforced
Branches are <kind>/<code>, commits are Conventional Commits, main/develop take no direct commits. Git hooks refuse the wrong move before it exists; CI refuses it on the pull request; the CLI and the MCP tools guide the right one. → Git-flow
Documentation
| Self-hosting | install.sh, compose, Dokploy, environment, upgrades, backups |
| Web app | organizations › projects › apps, setup wizard, code hosts, creating apps, releasing and deploying from the browser |
| CLI | every command |
| Git-flow | branch kinds, commit format, what hooks and CI refuse |
platform.toml |
the file that declares a project |
| Templates | the matrix and how to add to it |
| MCP | tools and prompts for AI clients, locally or against a hosted platform |
| Releases | versions per component, tags, what each publishes |
| Architecture | packages, the API, providers, how credentials travel |
| Development | running it locally, tests, regenerating the API client |
Extend it
Deploy targets are plugins. Implement the DeployTarget contract — preflight, create, deploy, switch_traffic, rollback, diagnose, delete — publish it under the action_platform.deploy_target entry-point group, and action-platform deploy finds it by name.
from action_platform import ActionPlatform, Config
from action_platform.providers.source.github import SourceGithub
tool = ActionPlatform(config=Config(source_host=SourceGithub(repo="acme/orders")))
tool.release("minor")
Templates are plain cookiecutters in actionplatform/templates. Add a stack or a cloud with a pull request — the CLI reads index.toml, nothing to redeploy. Point ACTION_PLATFORM_TEMPLATES at a local checkout while you work on them.
Ecosystem
| Repo | Role |
|---|---|
| templates | projects, clouds, services |
| ci-scripts | the one implementation of setup / check / release / commit lint |
| ci-github · ci-gitlab · ci-jenkins | thin wrappers per CI |
License
Apache 2.0.
1 maintainer
Release files for action-platform 0.4.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| action_platform-0.4.0.tar.gz | 67.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| action_platform-0.4.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 170.3 kB
Release files / action_platform-0.4.0.tar.gz
| Download URL | action_platform-0.4.0.tar.gz |
|---|---|
| Size | 67.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
542231c0b6fcfdbf7e2b0048d80cf679a1050b8ca71a1ff4a5a2322e531ca508
|
|
BLAKE2b-256 checksum How to use checksums |
dfde92d012b1da5d46878e776e76055f23a82957c6ce371aadfe3989c3ea70ff
|
| 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 Sep 13, 2026.
Transparency logRelease files / action_platform-0.4.0-py3-none-any.whl
| Download URL | action_platform-0.4.0-py3-none-any.whl |
|---|---|
| Size | 103.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e5a972231a641d5c1cff2512634ac72b2275bc8336708ed8b4cb89750b227928
|
|
BLAKE2b-256 checksum How to use checksums |
75fe7595b74220a2b376b57b6526af72dc1d5000876e7e6062d38e89c24b181b
|
| 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 Sep 13, 2026.
Transparency log
