GitHub Spark Ends August 31: What Keeps Working, What Already Broke, and What to Export

If you have an app in GitHub Spark, the August 31 deadline is not mainly about keeping the current URL alive. It is about keeping control of the app after the Spark workbench goes away.

GitHub says existing Spark users can access Spark until August 31, 2026 to export apps they already created. Apps that are already deployed will continue to work after Spark is retired. But GitHub’s built-in model service has already disappeared: GitHub Models retired on July 30, so Spark apps that call llm() have already lost that AI functionality.

The practical migration problem therefore has three separate parts:

1. source code — export it to a GitHub repository before August 31;
2. AI inference — replace llm() if the app uses it;
3. stored app data — audit and preserve it separately rather than assuming a code repository is also a database backup.

Status check: August 20, 2026. GitHub’s current retirement notice says deployed Spark apps will continue working after Spark is retired, but it does not publish a long-term end date for that hosted runtime in the retirement announcement. Treat continued hosting as breathing room, not as a substitute for owning a migration path.

The deadline in one table

That last row is where people can get a false sense of safety. “The app still opens” and “the app is safely migrated” are different states.

What keeps working—and what does not

GitHub’s official export instruction is specifically to save app code: open the Spark workbench, select …, then choose Create repository.

GitHub’s build documentation says this creates a new private repository under the personal account and includes the changes and commits made to the Spark before repository creation. While Spark is still operating, the Spark and the repository have two-way synchronization through the repository’s main branch.

That is a strong source-code escape hatch. It should not be confused with a complete application backup.

The biggest trap: code, inference, and data are three different migrations

A Spark app can look like one product in the browser while depending on several managed services underneath it.

1. Code

This is the clearest part. GitHub explicitly tells users to create a repository before August 31.

After creating it, do not stop at “repository exists.” Check that:

• the latest UI and application logic are present;
• the most recent Spark changes appear in the main branch;
• the commit history is there;
• the repository can be cloned or opened independently of the Spark workbench.

The goal is simple: if Spark disappeared from the interface tomorrow, could development continue from this repository?

2. AI inference

Spark’s built-in AI path used GitHub Models through the llm() function. GitHub Models was fully retired on July 30, including its inference API and BYOK endpoints.

GitHub’s Spark retirement notice says the fastest test is to search the code for:

llm(

If there are no calls, the GitHub Models retirement does not affect the app’s AI inference because the app was not using that Spark helper.

If calls exist, the app needs a replacement provider. GitHub says users must provide their own API key and manage provider billing going forward.

A sensible migration is to keep the old call site small and put a provider-neutral boundary around it:

UI / feature
    ↓
app inference function
    ↓
chosen model provider

That makes the next provider change less invasive than scattering provider-specific SDK calls throughout the application.

And do not put a permanent model API key into browser-delivered JavaScript. Use an appropriate server-side or protected backend path for credentials.

3. Stored application data

This is the least obvious part.

Spark can automatically create a managed key-value store for app data. GitHub’s documentation says the Data tab can be used to view and edit stored values, and Spark’s troubleshooting guide documents a maximum combined key-and-payload size of 512 KB per entry.

But GitHub’s retirement guidance describes Create repository as the way to save app code. The official documentation checked for this article does not say that creating the repository exports the live contents of the managed key-value store.

So the safe assumption is:

A repository is a source-code backup, not proof that live application data has been backed up.

If the data matters, inventory it independently before the deadline. For a tiny personal app that may mean recording or exporting the handful of important records through the app or Data tab. For an app with real users, build a repeatable export into a format you can import into the replacement database.

Do not wait until August 31 to discover which category the app is in.

A 20-minute Spark retirement audit

Step 1: create the repository now

Open each existing Spark app and use:

… → Create repository

Then open the repository separately and verify the latest code exists.

There is little upside to waiting for the final day. Exporting early also gives time to notice missing assumptions before the workbench closes.

Step 2: search for llm()

Search the whole repository, not only the file currently open in Spark.

If there are matches, list the user-facing features that depend on them: generation, summarization, classification, chat, search, extraction, or anything else.

Then test those features today. The model service they depended on is already retired, so failures are not a future August 31 problem.

Step 3: inventory Spark-specific dependencies

Make a small table for the app:

The value of the table is not technical sophistication. It stops “we exported the repo” from hiding a runtime dependency that only appears after the old environment is gone.

Step 4: inspect the Data tab

If the app persists anything, answer four questions:

1. What records exist?
2. Which records would be painful to recreate?
3. Can the app export them in a portable format such as JSON or CSV?
4. Where will they live after migration?

If the answer to question 2 is “none,” the migration becomes much easier. If the answer is “customer or production data,” this is now the highest-priority part of the project.

Step 5: test the deployed app from a clean session

Open the deployed app as a normal user and test the core path rather than just loading the homepage.

Check:

• sign-in;
• reads from persistent data;
• writes to persistent data;
• AI-dependent features;
• refresh/reload behavior;
• any external API integrations.

A deployment can still return HTML successfully while one critical managed feature has already failed underneath it.

Step 6: choose a migration depth

Not every Spark app needs the same response.

Three migration paths

Path A: keep the current deployment temporarily

This is reasonable when the app is already deployed, does not depend on broken llm() calls, stores little or no important data, and does not need active development.

Minimum action: create the repository anyway.

The weakness of this path is control. GitHub confirms that deployed apps continue after retirement, but the August 4 retirement notice does not provide a permanent hosting guarantee or a future shutdown date. If the app matters, keep an exit plan even if there is no reason to move it this week.

Path B: export the repository and replace AI inference

This fits an app where the main problem is llm().

The migration is then relatively contained:

1. export source;
2. choose an inference provider;
3. replace the Spark-specific call behind a small adapter;
4. put credentials in a protected runtime location;
5. add timeouts, error handling, and cost/rate limits;
6. retest the AI workflow end to end.

Do not treat this as a model-name swap. The old Spark runtime bundled inference into the platform; the replacement makes provider credentials, usage limits, and billing explicit application responsibilities.

Path C: move the whole application stack

Choose this when the app needs ongoing product development, contains important persistent data, or depends heavily on Spark-managed runtime features.

The order matters:

1. own the source;
2. own the data;
3. replace managed inference;
4. establish a new deployment path;
5. only then cut traffic over.

This avoids the nastiest migration failure: rebuilding the UI perfectly while discovering that the irreplaceable state was still trapped in an old managed service.

A simple decision guide

The key is to rank by recoverability, not by how impressive the app looks today.

What is confirmed—and what is not

Confirmed by GitHub as of August 20

• Spark stopped accepting new users and new app creation on August 4, 2026.
• Existing users have until August 31, 2026 to access Spark and export apps already created.
• Already deployed apps will continue to work after Spark retirement.
• Users who want to keep editing should create a repository before August 31.
• GitHub Models retired on July 30, 2026.
• Spark llm() calls no longer work because of that retirement.
• A Spark repository includes the Spark’s prior changes and commits when it is created.
• Spark can use a managed key-value data store, which is visible through the Data tab.

Not established by the current retirement notice

• a final shutdown date for already deployed Spark apps;
• that Create repository exports the live contents of the managed key-value store;
• that leaving a deployed app untouched is a permanent hosting strategy.

Those gaps are why the safest plan is to separate confirmed continuity from owned portability.

What to watch next

The most useful next GitHub update would be clarification about the long-term lifecycle of already deployed Spark apps and any recommended path for managed data as Spark retires.

For existing users, however, the important date does not need more clarification: August 31 is the code-export deadline GitHub has published.

The lower-risk move is to finish the reversible tasks first—create the repository, identify llm() calls, and inventory persistent data—before choosing a new hosting or model provider.

Conclusion

GitHub Spark’s retirement is unusual because the hosted app is not being switched off at the same time as the development experience.

That makes the deadline easy to underestimate.

A deployed app may continue to work after August 31, but future maintainability depends on what has been preserved outside the Spark workbench. And for AI-enabled apps, part of the break already happened on July 30 when GitHub Models retired.

Before August 31, do three things:

1. Create the GitHub repository.
2. Search for and replace llm() if it exists.
3. Treat persistent data as a separate backup/migration problem.

If those three pieces are under control, the Spark shutdown becomes a normal platform migration instead of an emergency recovery project.

Sources

Checked August 20, 2026:

• GitHub Changelog — Upcoming deprecation of GitHub Spark on github.com
• GitHub Docs — About GitHub Spark
• GitHub Docs — Building and deploying AI-powered apps with GitHub Spark
• GitHub Docs — Troubleshooting common issues with GitHub Spark
• GitHub Changelog — GitHub Models is now retired