hyfens
Start free

Product

Release, verify, and deploy with the boundary visible.

Hyfens turns a supported source change into a signed patch tied to an exact release, then carries it through verification and controlled delivery.
See pricing Read the quickstart

Release workflow

One path from release to rollback.

Each handoff has a concrete job. The same workflow can run through Hyfens Cloud or infrastructure your team operates.

  1. Release

    Create a production baseline.

    Record the release identity for the target before any patch is built.

  2. Patch

    Generate a signed change.

    Turn a supported source edit into a Patch Format v1 artifact with a bounded capability set.

  3. Verify

    Check the exact bytes.

    Inspect the digest, signature, capabilities, compatibility, and release binding before delivery.

  4. Promote

    Move a verified artifact forward.

    Use the organization, application, and environment scope to promote an admitted release.

  5. Deploy

    Deliver through the configured path.

    Upload and deliver the locally verified artifact through Cloud or a self-hosted control plane.

  6. Observe

    Keep release history visible.

    Inspect release, patch, deployment, environment, and audit activity in the operating workspace.

  7. Rollback

    Return to a trusted baseline.

    Record an explicit rollback to the store installed AOT base when recovery is required.

The commands stay close to the work.

The CLI keeps source, release identity, artifact verification, and delivery in one visible path.

Source checkout
# from a Flutter project
$ hyfens doctor
$ hyfens init
$ hyfens release android
$ hyfens patch android
$ hyfens verify <patch-path>
$ hyfens deploy

Normal source in. A bounded artifact out.

Build-time instrumentation supports a declared subset of ordinary Dart and Flutter source while normal Flutter AOT remains the fallback. The runtime interprets only a bounded, signed payload with capabilities owned by the release.

If the change needs a normal store release, the command surface says so. That stop is a correctness feature.

Open the Flutter quickstart

Framework support

Platform concepts stay neutral. Runtime support stays explicit.

Applications, environments, releases, artifacts, and audit history are platform concepts. Runtime adapters are named only when the implementation exists.

Planned

React Native

Planned product expansion. No React Native support is advertised yet.

A clear stop beats a risky success.

Native code, manifests, permissions, entitlements, dependency changes, and unsupported Dart or Flutter constructs are outside the patch boundary. Use a normal store release for those edits.

Boundary result
hyfens analyze
change: unsupported input
result: store release required

Verify what ships.

Read the security boundary, then choose Cloud or Self-hosted for the operating work around it.

Read security Compare plans