In June our generated apps ran in preview environments. I could inspect a screen while the pipeline changed it. That was useful during development. I would not put customers in the same environment.
We set out to separate production from that editing loop and give projects a GitHub handoff.
I described parts of it too confidently in the original release note. This revision separates the design from what we can verify on 15 October 2026. The implementation and documentation include deployment and GitHub paths. That alone does not verify every live rollout, domain change or rollback.
The production boundary
A preview rebuilds as you work. The design puts a deliberate release between that changing environment and the app people use. A production deployment should serve the version you chose.
The production host is designed to use prebuilt artifacts without preview editing tools. Production configuration and credentials have their own scope. The app’s end users also need their own identity configuration, separate from accounts used during development.
Storing a setting separately does not prove that every code path handles it correctly. Check the production values, allowed redirects and access rules before sending a customer a link.
Review the preview, including permissions and empty states. Configure the production environment, publish, wait for readiness, and run the important workflows against the deployed app.
The current publishing guide describes those steps and checks against your plan’s capacity. Treat a successful operation in the UI as a step in the release, then test the resulting service.
The domain
The domain workflow connects an app hostname to a domain you control. You need the relevant DNS records and must verify the connection.
The original article reduced that to attaching a CNAME and having everything work. That left out the waiting and checking a domain change requires.
Follow the values shown for the deployment. Verify the hostname, certificate and application after DNS resolves. Recheck sign-in redirects on the public address. A working preview URL tells you little about that last part.
We have implementation paths for domain setup. This rewrite is not a record of a fresh live DNS or TLS test.
The GitHub handoff
I want a project to have a useful life outside the session that created it. A repository gives source changes somewhere to be reviewed and maintained.
The GitHub integration has paths for connecting an account, publishing source, and exchanging changes with a connected repository. You can then inspect the project code and its supporting documents in familiar tools.
Publishing source to GitHub and publishing a running app are separate operations. A repository does not operate a database, configure your secrets or answer a production incident.
The history design uses one main branch, ordinary pushes, and forward revert commits to undo changes. We avoid offering force-push as a normal platform action.
That reduces the ways our own workflow rewrites history. It cannot justify a promise that a user will never lose code. Repository permissions, external edits and recovery procedures still matter.
In October, parts of history browsing and rollback behavior still lack fresh operational checks. Keep your own recovery plan. Do not infer a tested restore from a button or an implementation path.
Credentials and configuration
The integration’s design stores encrypted GitHub credentials per project, outside the app’s project disk. The app should not need a personal access token in its source tree to make the connection work.
That storage decision does not establish that the whole deployment has passed a security audit.
Moving a project elsewhere takes more than downloading source. You must supply the runtime configuration, data services and identity settings its code expects. Inspect those dependencies before choosing a hosting arrangement.
The Git and GitHub documentation explains the source workflow. The identity article covers why sign-in is only part of an application’s access boundary.
The release work
I still need evidence for the operational promises: a completed rollout, a working domain, a recovery exercised against the actual service. A code review cannot provide that evidence.
The June work gave us paths for those tasks. Writing down the checks they still need is less satisfying than calling the problem solved. It is also more useful before the first customer depends on it.
Originally published 16 June 2026. Revised 15 October 2026 to correct absolute deployment and recovery claims and distinguish implemented paths from live verification.