Repository runtime policy retired the permanent shared environment at
https://dev.stratofusion.io on August 5, 2026. This runbook governs the
remaining external shutdown. It does not authorize any external mutation.
Local Windows development, optional local-VM rehearsal, CI, and production at
https://stratofusion.io remain. Do not replace the retired environment with a
permanent staging deployment on the production VM. Temporary staging requires
separate, time-bounded migration or rehearsal approval.
Approval Boundary
Obtain explicit approval for each exact external target before changing it:
DNS record(s) for dev.stratofusion.io.
Vercel project/domain assignment for stratofusion-dev.
Neon development project, branch, database, and retained backups.
stopped Fly app stratofusion-rclone-dev.
development Clerk instance, allowed origins, and social connections.
Stripe test webhook endpoint and any dev-only test resources.
Google OAuth client, Microsoft Entra registration, and Dropbox app used by
the retired origin.
dev-only secrets, tokens, credentials, and callback registrations.
Git dev branch deletion or repurposing.
Do not probe or start stopped Fly Machines. Never print or copy secret values,
tokens, auth codes, full database URLs, or env-file contents into evidence.
Current Retention And Tombstone Defaults
Neon development data: retain by default until an owner records either
retention value and export requirements or an explicit discard decision.
Unknown value is not approval to delete.
DNS transition: a controlled static tombstone for about two weeks
is recommended because the hostname was long-lived. The tombstone must have
no sign-in, API, cron, webhook, database, rclone, or background-writer path.
An operator may choose immediate NXDOMAIN instead only with a recorded
rationale and confirmation that no client, webhook, callback, or support
workflow still relies on the hostname.
410 Gone
Ordered Procedure
1. Establish A Read-Only Baseline And Retention Decision
Record the exact project/app/resource identifiers without recording secret
values.
Identify owners, last observed use, data classes, retention obligations,
export format, and recovery expectations for Neon development data.
Confirm local .env.local and the local-VM configuration use local
PostgreSQL and test Clerk/provider/Stripe resources independently of the
retired Vercel origin.
Record one decision: retain, export then delete, or discard. A delete
decision needs explicit approval naming the exact Neon target.
Stop if local or local-VM work consumes any candidate integration. Separate or
document that dependency before continuing.
2. Disable Writers Before Data Or Routing Changes
In Vercel, verify the dev project's Git integration is disconnected.
Enumerate dashboard cron schedules. Disable each dev schedule and record its
path, former cadence, time, and verification evidence.
Enumerate other writers: Stripe webhooks, provider webhooks, queue workers,
scheduled jobs, external monitors with write callbacks, and manual deploy
hooks. Disable or prove each inactive.
Verify the authoritative VM still has exactly one production cron replica
and that local replay remains localhost-only.
Repository vercel.json having no schedules is useful evidence, but it is not
proof that dashboard schedules are absent.
3. Export Or Record Explicit Discard Of Neon Development Data
If retention is approved, create a dated, encrypted export in an approved
location, record its checksum, access owner, retention period, and a restore
test that does not touch production. If discard is approved, record the exact
project/branch/database, approver, date, and known recovery loss.
Do not delete Neon resources in this stage. Do not treat a connection string
or DNS switch as a backup.
4. Remove Dev Stripe Webhook Writers
Identify the Stripe test-mode endpoint whose destination is
https://dev.stratofusion.io/api/webhooks/stripe.
Confirm local development uses Stripe CLI forwarding to localhost and that
production live mode still targets the apex endpoint.
With approval for the exact test endpoint, disable/delete it and verify no
delivery retries remain.
Do not modify live-mode products, prices, customers, subscriptions,
endpoints, or secrets.
5. Remove Retired OAuth Origins And Redirects
After local and local-VM independence is proven, obtain approval for the exact
entries and remove only the retired origin from:
Clerk allowed origins and dev social-connection configuration.
Google direct callback and any dev Clerk callback no longer used locally.
Microsoft Entra Web redirect and any dev Clerk callback no longer used.
Dropbox redirect URI.
Verify localhost, exact local-VM callbacks (when intentionally retained), the
apex production callbacks, and the controlled production-rehearsal callbacks
remain unchanged. Never infer that a resource named dev is unused.
6. Revoke Dev-Only Credentials And Secrets
Inventory secret names and consumers, not values. After callbacks and writers
are inactive, approve and revoke only credentials proven exclusive to the
retired environment. Remove their references from Vercel, the stopped Fly dev
app, CI, Clerk, and provider dashboards as applicable. Verify local and
production startup/auth paths still use their intended credentials.
7. Optional Time-Bounded 410 Gone Tombstone
If approved, replace the old application with a static no-write tombstone on
the existing dev project for 14 days (maximum 28). Verify:
normal pages and former API/callback/webhook/cron paths return 410;
no Clerk, database, Stripe, provider, rclone, cron, or background-worker
configuration is present;
production and local traffic are unaffected;
the removal date and owner are recorded.
This is a retirement notice, not a shared development deployment. If immediate
NXDOMAIN is chosen, record why a tombstone provides no operational value.
8. Detach The Vercel Domain Before DNS Or Project Deletion
At the end of the tombstone window (or immediately for approved NXDOMAIN),
detach dev.stratofusion.io from the Vercel project first. Verify the project
no longer claims the custom domain and that no other project claims it. This
ordering prevents a dangling-domain condition when the DNS target or project
is removed.
9. Remove DNS
With separate DNS approval, remove only the exact retired record(s). Verify
authoritative and public resolution reaches NXDOMAIN/no-answer after TTL expiry
and that the apex, www, rclone, observability, email, and approved rehearsal
records are unchanged.
10. Delete External Resources Only With Separate Approvals
After observation and verification, request separate approvals before deleting:
Vercel stratofusion-dev.
the exact Neon development project/branch/database.
stopped Fly app stratofusion-rclone-dev.
unused Clerk instance or social connections.
unused Google, Microsoft, Dropbox, Stripe test, or other identity resources.
Deletion approval for one resource does not authorize another. Capture the
platform's deletion result and known recovery limits without copying secrets.
11. End-To-End Verification
Verify all of the following after every destructive stage:
production app, PostgreSQL, rclone, TLS, observability, backups, and exactly
one VM cron replica are healthy;
production Google, Microsoft, Dropbox, Clerk, and Stripe live flows retain
apex callbacks and expected modes;
local app, local PostgreSQL, local rclone, local cron replay, and Stripe CLI
forwarding still work;
local-VM rehearsal still uses its exact hosts-file origin and test resources;
CI passes environment, host, CORS, cron, OAuth, type, lint, and relevant
worker tests;
the retired hostname returns the intended 410 during the window or no
longer resolves afterward;
stopped Fly production recovery resources were not probed, started, or
altered.
12. Closeout Evidence
Record:
every deleted, disabled, detached, revoked, exported, and retained item;
exact targets, approvals, timestamps, operator, and verification result;
data-retention decision, export checksum/location owner, and restore proof;
tombstone choice, dates, and NXDOMAIN verification;
production and local/local-VM smoke results;
recovery limitations and residual cost/ownership.
Rollback Limits
Before destructive deletion, rollback may re-enable a schedule, reattach a
domain, or restore a callback only if doing so does not reintroduce writers or
mix environments. After credential revocation, resource deletion, or database
deletion, recovery may require new credentials, a platform support request, or
a tested export restore.
DNS-only rollback is never sufficient after any replacement database accepts
writes. Database state must be reconciled deliberately before traffic moves.
Git dev Branch Recommendation
The branch is not an application deployment source. Review unique commits,
open work, protection rules, CI consumers, and references. Then request
explicit approval to either archive/delete it or document a CI-only purpose.
Do not delete, rename, or repurpose it as part of this runbook without that
approval.