Apply & deploy
Follow a Business program from local build through Git-triggered validation, publication, and recovery.
Follow a Business program from local build through Git-triggered validation, publication, and recovery.
The managed repository owns the business contract: routes, plans, pricing,
meters, limits, policies, and surfaces under business/. FartherShore owns the
operational records produced when that contract is built and applied.
There is no imperative apply command. The normal path is:
edit business/ -> farthershore build -> commit -> push
-> Build business -> Compile -> Accept -> Publish -> optional billing sync
farthershore build --format json
This runs the repository build locally. It does not update a live environment. Fix SDK, reference, validation, and determinism errors before committing.
env/payments may create and build the
corresponding preview environment.An existing preview environment continues rebuilding from its bound branch even when automatic preview creation is disabled. The trigger policy decides whether new environments are created; it does not orphan existing ones.
| Phase | Meaning |
|---|---|
| Build | Execute the repository's Business program and produce the build artifact. |
| Compile | Validate and compile the artifact into platform state. |
| Accept | Record the accepted repository contract for this target. |
| Edge publish | Make the compiled routes and enforcement state available for the environment. |
| Billing | Reconcile economic state when the accepted change requires it. |
Each phase reports pending, running, succeeded, failed, or skipped.
Read them with apply-timeline; do not infer publication from a local build or
from the compile phase alone.
farthershore apply-timeline list acme --env all --format json
farthershore apply-timeline inspect acme <sha-or-tag> --env production --format json
The Business program compiles the contract. A customized frontend has its own build and release records. A contract-only push need not create a frontend build, and a frontend rollback does not restore routes, plans, or pricing.
farthershore frontend status acme \
--ref "$(git rev-parse HEAD)" \
--wait \
--format json
There is intentionally no CLI frontend-deploy command. Preview deployment is
triggered by its branch push; production deployment is triggered by the GitHub
Release. For either Git event, --ref observes the latest known build for the
exact source revision, not a specific webhook delivery. The CLI observes status
and can reactivate a prior frontend release.
Nothing new was accepted. Fix the repository and push a new commit. Inspect the failed entry rather than retrying an imperative platform write.
The intended snapshot did not finish publishing. Keep the repository as the source of truth, inspect the phase error, fix it if repository-owned, and push again. If the error is platform infrastructure rather than business input, capture the entry id, commit SHA, environment, and error code for support.
Prefer a reviewed forward fix in business/ followed by a new release. For an
urgent operational compensation, business rollback can enqueue a rollback
workflow against the prior publish workflow; it does not rewrite Git history or
change the repository contract. See Production releases.
Reactivate a known frontend release without changing the Business program:
farthershore frontend status acme --format json
farthershore frontend rollback acme --release-id <releaseId> --format json
After any recovery, use the Apply Timeline to confirm which repository contract
is still accepted, then read the recovered surface itself (business status,
frontend status, or workflow detail). A successful enqueue is not proof of
convergence, and the source publish's timeline status is not the new rollback
workflow's status.