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 › teams › projects › apps, with roles (owner, admin, deployer, developer, viewer). Create an app from a template or import any repository, connect GitHub / GitLab / Bitbucket, edit platform.toml, open pull requests, cut releases, see whether each one can reach dev and prod, deploy it, follow the CI runs and every deployment — wherever it ran — from a dashboard, a release timeline and paged tables. One command to self-host. |
| CLI | pipx install action-platform and the same verbs on your machine: init, branch, pr, release, readiness, deploy, rollback, diagnose, deployments. |
| MCP server | The same operations as tools for Claude Code, Codex, Cursor — locally, or against your hosted platform after action-platform login: 38 remote tools that know who you are, which app the current directory is, what your token may do, and can manage projects, teams and members. |
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 source 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 → readiness → deploy → rollback → diagnose → destroy. Same verbs for a Python API on Lambda, a Go service in Docker, a React app on Amplify. |
| A deploy is always a release — and it knows if it will make it | Every deployment references a tag. Right after a release is cut, the platform checks whether it can reach each stage — configuration, manifests, credentials, permissions, the destination's state — without building anything, stores the verdict, and refuses a blocked deploy unless you say so. Deployments are recorded whoever ran them (the platform, GitHub Actions, Jenkins, a person) and verified at the destination — PyPI, npm, a registry, a stack. |
| 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, Jenkins or Bitbucket Pipelines you already have — connected to the platform, their runs show next to your releases and a click starts one. Repositories on GitHub, GitLab, Bitbucket or any git server, connected with OAuth; webhooks keep the platform level with them. 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, ci-bitbucket). Bump v1, every project picks it up. |
| Roles, scoped tokens | Members join by invitation or are added with an account; viewer reads, developer branches and commits, deployer releases, admin and owner run the organization. action-platform login mints a token with a scope (read, write, release, admin) and a reach (one organization or all, a project, an app) that never exceeds your role. Connected apps shows every token, which program uses it — Claude Code, Codex, Cursor, the CLI — and every browser session, all revocable. Source-host credentials stay on the platform. |
What you get
| Type | Stacks |
|---|---|
web |
python (FastAPI, FastMCP), go (Gin), node (Fastify, React), java (Spring), kotlin (Spring), ruby (Sinatra) |
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. Your organization can add any git repository as a template — a plain starter becomes one template, a repository with an index.toml a whole catalog. Existing repositories join with one click: the platform installs platform.toml, code quality, CI and hooks, and opens the pull request. → 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
From the browser
flowchart LR
T[Templates<br/>official + your repositories] --> A[App<br/>clone on the platform]
R[Existing repository] -->|install platform.toml, CI, hooks| A
A --> C[Configuration<br/>deploy targets · services · platform.toml]
C -->|commit on chore/<code>| P[Pull request]
A --> B[Activity<br/>branches · pull requests]
A --> W[CI<br/>runs · start one]
A --> V[Releases<br/>stable from main · rc elsewhere]
V --> K{Readiness<br/>dev · prod}
K -->|deployable| D[Deployments<br/>platform · Actions · Jenkins · manual]
D --> I[(verified at PyPI · npm · registry · stack)]
Documentation
docs/ is organized by what you want to do — start, use, concept, contribute:
| Start | Getting started · Self-hosting · Troubleshooting |
| Use | Web · CLI · MCP · API · Plugins |
| Concept | Access control · Git-flow · Manifest · Templates · Releases · Deployments · Identity · Observability · Database |
| Contribute | Architecture · Development · Writing a plugin · Decisions |
Versions and history: LAST_VERSION / CHANGELOG.md for the library and CLI, apps/web and apps/api for the web app and the API.
Extend it
Everything is a plugin. Deploy targets (preflight, deploy, verify, readiness), CI runners, source hosts, release strategies and changelog formats are named providers behind entry-point groups; git-flow rules, the releaser, the deployer, the readiness checks, the installer and the scaffolder are slots a plugin replaces with a subclass; MCP tools, CLI commands and cloud overlays ride along. action-platform plugin install aws-lambda — see plugins.
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, or keep your own repository next to the official one: action-platform init --source https://github.com/acme/templates.git@main, or Templates → Add repository in the web app.
Ecosystem
| Repo | Role |
|---|---|
| templates | projects, clouds, services |
| ci-scripts | the one implementation of setup / check / release / commit lint |
| ci-github · ci-gitlab · ci-jenkins · ci-bitbucket | thin wrappers per CI |
Contributing
Read CONTRIBUTING.md first — git-flow branches, Conventional Commits, one pull request per change, discussion before anything large. Everyone in the project's spaces follows the Code of Conduct. Vulnerabilities go through SECURITY.md, never through a public issue.
License
Apache 2.0.
1 maintainer
Release files for action-platform 0.27.1
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.27.1.tar.gz | 119.2 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| action_platform-0.27.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 286.5 kB
Release files / action_platform-0.27.1.tar.gz
| Download URL | action_platform-0.27.1.tar.gz |
|---|---|
| Size | 119.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4fceab8534e3ef48641c9927286247095cfb3fcfa2fffea779743a0b366b32bf
|
|
BLAKE2b-256 checksum How to use checksums |
fc1779dcec3e42fa5659838db538329092ffaa853157f468d6bbe9ffcaeaa4af
|
| 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 19, 2026.
Transparency logRelease files / action_platform-0.27.1-py3-none-any.whl
| Download URL | action_platform-0.27.1-py3-none-any.whl |
|---|---|
| Size | 167.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
9ed5c90b10d592919e16f9cfd416ad900d0ae4878c14f71ef07d202b2b1fe385
|
|
BLAKE2b-256 checksum How to use checksums |
6292f1388f2bd55ef112dee01a57c71202bd64da6bc14e3447e30ac9ee828bd4
|
| 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 19, 2026.
Transparency log
