Kodmos
Get started
LiveEvery deploy, watched step by step

Release day,
in the right order.

Every team adds the branch that is ready. At the deadline the list locks, and DevOps ships it as a chain of GitHub Actions deployments: when one finishes, the next one starts.

Continue with GitHubTake the tour
Release 4.2 deploying in Kodmos: the Core API and the billing worker have succeeded, the web app is running with its jobs streaming in, and the mobile gateway waits for both.Release 4.2 deploying in Kodmos: the Core API and the billing worker have succeeded, the web app is running with its jobs streaming in, and the mobile gateway waits for both.

Product

The whole release, on one screen.

Plan it with the teams that own the code, chain the deployments once, and watch every step as GitHub runs it.

Plan

One list for the whole release.

Each project’s owners add the branch that is ready, checked against GitHub with its latest commit. Everyone can see who is still missing.

The Release 4.3 event collecting branches: the Core API and the web app have answered, with branch, commit and a note.The Release 4.3 event collecting branches: the Core API and the web app have answered, with branch, commit and a note.

Notify

Everyone hears about it.

One email per person, only to the people involved, never to whoever caused it. Each with just the projects that concern them.

The Release 4.2 shipped email, listing each project's result.The Release 4.2 shipped email, listing each project's result.

Watch

Every step, as it happens.

Each box shows its GitHub run live: queued, waiting for approval, running, done. Open one to follow its jobs, retry it, or run on from there.

The web app's deployment: running for 33 seconds, built from feature/new-checkout.The web app's deployment: running for 33 seconds, built from feature/new-checkout.
Its jobs: build done, push-image running step by step, deploy waiting.Its jobs: build done, push-image running step by step, deploy waiting.

Chain

Deployments that hand off to each other.

Draw a flow once. Connect the boxes on success, on failure for rollbacks, or always. Inputs come from the workflow file, so an environment is a dropdown.

The flow editor: Core API hands off to the web app and the billing worker, then the mobile gateway, with a rollback if the API fails.The flow editor: Core API hands off to the web app and the billing worker, then the mobile gateway, with a rollback if the API fails.

Your week

What needs you, and what is going out.

Home starts with the branches you owe, then what is deploying right now and every release coming up.

Home: three events need a branch from you, and Release 4.2 is deploying, two of five steps done.Home: three events need a branch from you, and Release 4.2 is deploying, two of five steps done.

Oversee

Every flow, at a glance.

Each flow with its latest deploy, so a red step anywhere is hard to miss.

Four flows with their latest deploys: Hotfix and Infrastructure succeeded, Production release running, Staging release failed.Four flows with their latest deploys: Hotfix and Infrastructure succeeded, Production release running, Staging release failed.

Auto-start

A push to staging, or someone pressing Run workflow on GitHub, starts the rest of the flow from that run.

Environment approvals

Protection rules still apply. A run waiting for a reviewer shows as Needs approval, and the chain waits with it.

Retry, or run from here

Retry a failed deployment and the chain carries on from there. Every attempt keeps its own GitHub run.

Reminders that target

A day and two hours before the deadline, only to the people whose projects are still waiting.

Member, DevOps, Owner

Anyone plans and answers; DevOps deploys; the owner decides who gets in. Enforced by the API.

Duplicate a flow

Turn the Test release into the Production one in a click. Auto-start is off on the copy.

How it works

From plan to shipped.

A deployment event is a release day. It moves through five steps, and the right people hear about each one without anyone chasing.

  1. Oct
    29
    Thu
    Release 4.3
    17:00 · 3 teams
    01

    Plan

    Anyone plans a release day: the date, the teams, the flows that ship it, a deadline for branches.

  2. release2/4
    02

    Collect branches

    Owners add the branch that is ready, or say it is not shipping. Reminders go to whoever is still missing.

  3. Locked · 4 ready
    03

    Lock

    At the deadline the list locks itself. The planner and DevOps hear when every project has answered.

  4. Deploying2/4
    04

    Deploy

    DevOps deploys. Every flow starts at once, and each repository runs from its branch, in order.

  5. Shipped
    6 people emailed
    05

    Shipped

    Everyone involved gets each project’s result. A failed step is retried from the event, same branch.

Use cases

Built for the way releases actually go.

The same three ideas, events, flows and teams, cover the weekly train, the 6 pm hotfix and everything in between.

All use cases

How to run a weekly release train across GitHub repositories

Platform, Web and Mobile each add a branch by Wednesday; on Thursday the API ships first, then everything that talks to it.

Read the guide3 min read

Ship a hotfix with the rollback already armed

One branch straight to production. If the API fails, the rollback runs on its own and the web app is skipped.

Read the guide2 min read

Deploy staging on every push, across repositories

Auto-start attaches to the workflow GitHub ran for a push and carries the chain on from there.

Read the guide2 min read

Ship infrastructure before services, with environment approvals

Cluster changes wait for the environment’s reviewers; the worker that depends on them starts only once they are done.

Read the guide2 min read

Customers

Quieter release days.

“Release day used to be a forty-message thread and a spreadsheet nobody trusted. Now it is one page: which branch each project ships, who still owes us one, and what went out.”
Hana Okafor
Engineering Manager, Tidewell
“The API failed at six on a Friday and the rollback was already running before anyone had GitHub open.”
Marek Dvořák
Staff SRE, Ostrava Freight
“We ship eleven repositories in a fixed order. Kodmos is the first tool that understood the order is the whole point.”
Sofia Lindgren
Head of Platform, Pinemark Health
“Our mobile team stopped asking whether the gateway went out yet. They get the email when it does.”
Daniel Achterberg
Mobile Lead, Arbor Ledger
“Access stays with our org owner, the GitHub permissions are minimal and environment approvals still apply. Security signed it off in a day.”
Ruth Abebe
Security Engineer, Kestrel & Finch

Security

Asks GitHub for very little.

Kodmos is a GitHub App. Your organization’s owner installs it on the repositories it may see, and runs are started by the app, so GitHub shows who did what.

  • Access is always granted by the owner, never automatically.
  • People who leave the organization on GitHub lose their access here too.
  • Environment protection rules still apply; Kodmos waits for approvals.
  • Every rule is enforced by the API, not just hidden in the interface.
PermissionAccess
ActionsRead and writeStart and cancel the workflow runs in your flows
ContentsReadList branches, read workflow files and their inputs
MetadataReadRequired by GitHub for every app
Organization membersReadOnly people in the organization can be invited or ask
Email addressesReadWhere each person’s email goes

Plan your next release in Kodmos.

Connect your GitHub organization, invite your team, and put the next release day on the calendar.

Continue with GitHubSign in