Request a demo
APPII Release

Know what every customer runs.
Ship to exactly who you mean.

A release is one versioned manifest of every layer you ship: product, platform, infrastructure, configuration, schema and feature flags. APPII Release sends it to the targets a saved rule matches, in waves, with approvals and checked rollbacks. Your CI/CD deploys. We keep the record.

Request a demo See how it works
  • Version matrix
  • Waves and approvals
  • Checked rollbacks
  • Audit trail
> RELEASE 4.2.0 · CLAIMS CLOUD
“Pilot and internal rings first. Production needs approval. Northwind EU cannot roll back past schema v58, so we plan a fix forward.”
1Ring: Internal · 2 targetsVerified
2Ring: Pilot · 3 targetsVerified
3Ring: General · 7 targetsAwaiting approval
Why APPII Release

Releases are rarely one version.

The code is only one layer. Platform, infrastructure, configuration, schema and flags each move on their own, and every customer can sit on a different mix.

ϟPipelines deploy.
Release keeps
the ledger.
▦

One source of truth

A matrix of every deployment target against every layer, with each target's standing against the latest release.

◎

Targeted, not broadcast

Select by customer or by your own dimensions such as environment, region, hosting or ring. Save the rule and reuse it.

≋

Waves you control

Order waves by a dimension such as release ring. Production targets need approval before they start.

⟲

Rollbacks that are checked

Redeploying an old version does not undo a destructive schema change. Release tells you when rollback is blocked and plans the fix forward.

✉

The right customers, told

Notices go out before a wave, when it starts, when it is verified and on rollback, scoped to each contact's region or audience.

▤

An audit trail you can trust

Every state change is recorded in an append-only trail, readable by anyone who has to answer what changed and when.

How it works

From setup to a verified rollout.

Configured per product, in your words, not ours.

  1. 01

    Describe the product

    Pick a template or start blank. Define layers, dimensions and which one marks production.

  2. 02

    Import targets

    Paste a CSV. Rows are checked against your setup and recorded as each target's baseline.

  3. 03

    Plan the release

    Enter the manifest and a selection. Compatibility rules refuse combinations that cannot work.

  4. 04

    Approve

    Production targets need an approval. Notices for each wave are scheduled.

  5. 05

    Deploy and report

    Your pipeline deploys and reports per target. Statuses map onto one lifecycle.

  6. 06

    Verify or roll back

    Verified targets update the matrix. Failed ones can be rolled back, or fixed forward.

What every target runs

New release
12deployment targets
6on 4.2.0
5behind the latest
EnvironmentRegionReleaseProductSchemaStanding
Northwind Health
Productioneu-west-14.2.04.2.0v58Current
Productionus-east-14.0.54.0.5v55Behind
Kestrel Insurance
Productionca-central-14.0.54.0.5v55Behind
Rollback to 4.0.5 is blocked for Northwind EU: schema v58 drops a column. Plan a roll-forward fix.
The product

See the whole estate at a glance.

Rows are deployment targets. Columns are your own dimensions and layers. Select a row for its history or a checked rollback.

  • Versions are always exact: shown in mono, compared with the latest release and highlighted where they differ.
  • Targets change only through reports: an import sets the baseline, then only deployment reports and rollbacks move a target.
  • History per target: baseline, deploys and rollbacks with who, what and when.
  • Built for your vocabulary: layers, dimensions and values are yours.
Safety

Guardrails before the deploy, not after.

Two rules are decided in one place, so every plan and every rollback is judged the same way.

Compatibility checks

  • Rules such as "product 4.2 needs platform 2.4 or newer"
  • Incompatible manifests are refused when planned
  • The same rules apply to previews and releases

Irreversible versions

  • Mark a schema version as destructive, with the reason
  • Rollback past it is blocked for every affected target
  • Release offers a roll-forward fix instead

APPII Release coordinates. Your CI/CD deploys and reports back.

Works with your pipeline

Report from the tools you already use.

Pipelines post one deployment report per target. Common statuses from GitHub Actions, GitLab, Argo CD and Jenkins map onto one lifecycle.

Your CI/CDdeploys the targets
→
APPII Releasepending · in progress · deployed · verified · failed · rolled back
→
Matrix, notices, auditkept up to date
Per-target reportingIdempotent updatesAppend-only auditContext-scoped access
Get started

Who runs what, and what ships next?

Tell us how you ship today and how many customers or environments you track. We will show you APPII Release on a setup that looks like yours.

No technical specification required.