Automate stable workspace public-site provisioning
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 71
- Forks
- 64
- Avg merge
- 15h 38m
- Merged PRs (30d)
- 66
Description
Goal
Automatically provision a dedicated stable public site per workspace/service.
Today FACILITY_PREVIEW_SITES supports exact bindings, but an operator must create
the distribution, update configuration and refresh the API. Merging Compose code
alone does not create a public origin.
This remains a follow-up after the manual-site integration pilot for AIFindr D3
(theam/aifindr-dev-environment#30). Generic story facts, integrationState and GitHub
notifications are now in #374 / #375; the project-owned Auth0 consumer is in
theam/aifindr-dev-environment#31. They are not part of provider provisioning here.
Incremental plan
- Add a provider-neutral stable-site provision/reconcile contract, initially for
the CloudFront path supported by the internal deployment. Bind exact
org/project/workspace/service idempotently and persist provider identity. - Create a disabled distribution/per-site credential, register and read back the
mapping, refresh configuration, then publish the configured origin after gateway
routing/authentication checks. Do not require the app's Auth0 login before
reporting the origin: its consumer needs that origin to register the callback. - Keep site/storage separate from compute. Suspension retains identity. Never
reassign browser origins across workspaces; coordinate retirement so external
cleanup finishes before removing its configuration/tombstone. - Make site changes observable by the generic lifecycle notification mechanism.
No Auth0-specific script or provider credentials in agent workspaces. Consumers
own business policy and use Facility's generic integration state if needed. - Add a scoped operator workflow in the private deployment repository. Existing
release-on-merge remains; its role currently does not provision CloudFront sites
or write preview configuration. Review exact IAM, cost and secret targets with
deterministic fake-provider/denial/recovery tests before live application.
Acceptance
A fresh story obtains an isolated root-origin site without manual per-story cloud
work. Sleep/resume retains identity. Public origin publication enables project
integrations to complete login setup; retired stories can clean owned registrations
without destroying retained work. A second story is isolated. Failed/partial
provisioning and retries cannot duplicate, cross-bind or expose a workspace.
No automatic provider or real D3 preview is claimed by creating this issue.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the existing manual-site integration and CloudFront path in the private deployment repository; the issue does not identify files or tests. Trace configuration refresh, gateway routing and authentication checks, lifecycle notifications, and the provider boundary before defining the reconcile contract. Done means isolated, idempotent provisioning with retained identities, safe retries and recovery, scoped cleanup, and deterministic fake-provider and denial tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100