How Farther Shore works

Farther Shore puts the commercial and access-control layer around your software: customer identity, plans, checkout, API credentials, gateway authorization, limits, usage collection, hosted customer UI, and business operations.

You work through two surfaces with a clear ownership boundary.

Repository-owned contract#

The managed repository answers what the business is. Its business/ TypeScript program declares routes, plans, prices, meters, counted resources, limits, policies, call surfaces, backend identities, and managed RBAC.

Change that state by editing the program, building it, and pushing Git:

business/ source → deterministic Manifest IR → Git check → accepted contract

The platform never edits the business program back into the repository. A successful push is the handoff from authored intent to the control plane.

Platform-owned operations#

The CLI answers what is happening now. Use it for state that is not source code: selecting an organization, inspecting apply checks, binding deployed backends, managing environments and runtime variables, publishing, observing usage, and operating customers.

farthershore operations list --format json

That command is the current machine-readable catalog. Each entry says whether the operation belongs in the repository or has an executable CLI command.

The creation handoff#

There is one business-creation path:

CREATE_ATTEMPT=$(node -e 'console.log(crypto.randomUUID())')
farthershore business create quillby \
  --idempotency-key "$CREATE_ATTEMPT"

Human output is exactly the managed repository URL. The command does not report success until that repository exists. The repository starts with tooling and instructions, not a sample plan, route, meter, or frontend; you author the real business from its requirements.

For shell automation:

REPO_URL=$(farthershore business create quillby \
  --idempotency-key "$CREATE_ATTEMPT")
git clone "$REPO_URL"

The normal lifecycle#

1. Run farthershore login and select an organization if necessary.
2. Create the business and clone the returned repository.
3. Author one deterministic business/ program.
4. Build locally, commit, and push.
5. Inspect the repository checks and the Apply Timeline.
6. Bind runtime infrastructure and test in a preview environment.
7. Publish only after reviewing the business and commercial-release diff.
8. Observe and operate the live business through the CLI.

Continue with the Quickstart, then use Core concepts as the ownership reference.