Upcoming deprecation of GitHub Spark on github.com

[ebndev]

Beginning August 4, 2026, GitHub Spark no longer accepts new users or allows the creation of new apps. Existing users can continue to access GitHub Spark until August 31, 2026 to export apps they’ve already created. Apps you’ve already deployed will continue to work after GitHub Spark is retired.

GitHub Spark was created to help people quickly move from an idea to a working application. Since its launch, AI models and agentic development tools have advanced significantly. Builders can now build and refine these experiences through GitHub Copilot in the environments where they already work, including VS Code, Copilot CLI, and the GitHub Copilot app. We’ve seen builders increasingly choose these integrated workflows for application development, and we’re aligning our experiences accordingly. This change applies specifically to the current GitHub Spark experience on github.com.

Separately, GitHub Models, the inference service used by Spark’s llm() function, retired on July 30, 2026. As of that date, calls to llm() no longer work. Apps that don’t use llm() aren’t affected by the GitHub Models retirement.

What this means for you

• Existing apps you’ve already deployed will continue to work after GitHub Spark shuts down.
• Export your app code before August 31, 2026 if you want to keep editing your app in the future. To do this, open the Spark workbench for your app, select ..., then select Create repository.
• If your app uses llm(), replace it with your own inference provider to keep AI features working.

Not all Spark apps use AI inferencing. To check whether an app is affected by the GitHub Models retirement, open the app in Spark and search the code for llm(). If there are no llm() calls found, no action is needed. If the app does use llm(), replace inferencing with a separate provider to keep the app running with AI capabilities. Users will need to supply their own API key and manage billing going forward in this instance, as GitHub will not provide the underlying model or tokens any longer.

For questions and feedback, please leave a comment below.

[thesomewhatyou]

Why was it discontinued? There was no reasoning for it at all.

[sandstrom]

Because ~nobody used it

[The-Jay-M]

This was sad for those working in quarantined environments and needed to throw up prototype to set up a functional process tool. This was nice to have. We hope for viable options. Thanks

[spboyer]

For anyone exporting a Spark app and wanting to continue developing it, I published a Copilot CLI conversion plugin that migrates the application into an Aspire + Microsoft Foundry architecture.

GitHub Spark source	Converted solution
React/Vite UI, routes, components, and assets	Preserved as an Aspire-managed web resource
useKV persistence	Service-owned Node API with SQLite persistence
spark.llmPrompt, spark.llm, or llm()	Python Agent Framework Responses service backed by a Microsoft Foundry model and hosted agent
Spark runtime configuration	TypeScript Aspire AppHost with service discovery, health, logs, and traces

The skill inventories the app, coordinates the current Aspire and Microsoft Foundry skills, removes Spark-specific residue, and validates the converted application end to end.

Repository and installation instructions: https://github.com/spboyer/spark-to-aspire

[SatoMini]

For anyone using the remaining export window, I would treat exporting the repository and migrating the application as two separate jobs.

Before August 31, I would do the following for every existing Spark app:

1. Use … → Create repository, then open the repository and verify that the latest source files, assets, configuration examples, and recent changes are actually present.
2. Record the deployed app URL, repository URL, last known working state, and any external services the app depends on.
3. Search the exported code for llm(), spark.llm, spark.llmPrompt, model endpoints, and related environment-variable names. A page that still loads may still have broken AI functionality.
4. Keep replacement API keys in the deployment platform’s secret storage, not in the repository, and rotate any key that was accidentally committed.
5. Check data storage, authentication, permissions, and deployment separately. Creating a repository preserves the code, but it does not prove that those platform-managed parts have been migrated.
6. Preserve a rollback point before replacing the inference provider, then test success, timeout, rate-limit, authentication-error, and empty-response paths.

I wrote a more detailed Chinese checklist covering the export, dependency inventory, llm() search, provider replacement, and post-export verification here: How to export apps before GitHub Spark is deactivated on August 31