GitHub Spark Is Shutting Down: What to Use Instead

GitHub Spark is retired. As of September 30, 2026, you cannot sign up, create a spark or open the Spark workbench: GitHub stopped accepting new users and new apps on August 4, 2026, and existing users could reach Spark only until August 31, 2026 to export their apps. Apps you already deployed keep working, with one large exception. GitHub Models, the inference service behind Spark’s llm() function, was retired on July 30, 2026, so any AI feature built on llm() has stopped answering. GitHub now points builders to Copilot in VS Code, Copilot CLI and the GitHub Copilot app.

What GitHub Spark was

Spark turned a description into a working web app. GitHub’s public preview announcement↗ (opens in a new tab) from July 23, 2025 described natural language to app with front end and back end included, and “no setup required”: data storage, LLM inference, hosting, deployments and GitHub sign-in all came with it. You could publish with one click, create a repository from a spark, open it in a codespace, and hand work to Copilot. It launched for Copilot Pro+ subscribers, and Spark messages used premium requests from a Copilot plan.

That bundle is why the shutdown matters. A spark was not just code; it leaned on services GitHub ran for it, and those services are the part that goes away.

The timeline

• June 16, 2026: GitHub Models closed to new customers, as a first step toward retiring it.
• July 16 and July 23, 2026: scheduled brownouts, when GitHub Models requests returned errors for short periods.
• July 30, 2026: GitHub Models fully retired, including the playground, model catalog, inference API and bring-your-own-key endpoints. From that date, llm() calls in Spark apps no longer work.
• August 4, 2026: Spark stops accepting new users and new apps.
• August 31, 2026: last day existing users could open Spark and export their apps.

GitHub’s Spark retirement notice↗ (opens in a new tab) gives the reason plainly: models and agentic development tools have advanced, and builders now build and refine these experiences with Copilot in the environments they already work in, so GitHub is aligning its products accordingly. The notice says the change applies to the Spark experience on github.com. Spark’s old documentation and product pages now redirect: the docs to that notice, and the product page to GitHub Copilot.

What still works

• Deployed apps: GitHub says apps you already deployed continue to work after the retirement.
• Apps without AI: if your code has no llm() calls, the GitHub Models retirement does not affect it.
• AI features: anything that called llm() fails. GitHub will no longer supply the model or the tokens.
• Editing: the Spark workbench is gone, so a deployed app can no longer be changed in Spark.
• Stored data: the notice says nothing about the data store sparks used. If your app saves data, check it still reads and writes, and copy out anything you need now.

Getting your code out

The export route GitHub gave was: open the app in the Spark workbench, select the menu, then Create repository. If you did that before August 31, or created a repository for the spark at any point earlier, the code sits in an ordinary repository in your account. Clone it, or open it in a codespace and start it with npm run dev, the local workflow GitHub described in its September 2025 Spark update↗ (opens in a new tab).

git clone https://github.com/YOUR-ACCOUNT/YOUR-SPARK-REPO.git
cd YOUR-SPARK-REPO
npm install
npm run dev
grep -rn --exclude-dir=node_modules "llm(" .

If you did not export before August 31, GitHub’s notice describes no later route. The notice links a GitHub Community discussion for questions, and that, or GitHub Support, is the place to ask; do not count on a recovery path until GitHub confirms one. A deployed app that still runs is at least a working reference you can rebuild from.

Replacing llm() and the other built-in services

GitHub’s advice is to search the code for llm() and, where it appears, replace it with your own inference provider, supplying your own API key and managing billing yourself. The GitHub Models retirement notice↗ (opens in a new tab) suggests Microsoft Foundry for model access. Any provider with a server-side API works, with one rule from vibe coding security worth repeating: the key goes in a server-side environment variable, never in code that ships to the browser.

This is a good first job for a coding assistant, because it is mechanical and easy to check. Something like: “Find every llm() call in this repository. For each one, tell me what the feature does and what the prompt is. Then replace the calls with a single server-side helper that reads the API key from an environment variable, and stop there so I can test it.”

Then list what else the spark got for free, because an exported app still has to live somewhere. Spark provided hosting, deployments, data storage and GitHub sign-in. For each one your app uses, pick a replacement, and decide which of them you actually still need before rebuilding all four.

What GitHub points to instead

GitHub names three Copilot surfaces. They are coding tools rather than an idea-to-hosted-app builder, so they suit you if you are willing to own a repository:

• Copilot in VS Code: agent mode in the editor, where you watch changes land file by file. The VS Code Copilot overview↗ (opens in a new tab) is the starting point.
• Copilot CLI: one agent in a terminal, good for a repository you already cloned. Setup is in GitHub Copilot CLI.
• The GitHub Copilot app: a desktop app that runs several agent sessions side by side with issues and pull requests in the same window. See the GitHub Copilot app.

Other app builders

If what you liked was describing an app in a browser and getting a hosted result, the closest replacements are the browser builders. Each has its own stack, hosting and limits, so read the detail before moving a live app:

• Bolt.new: a full development environment in a browser tab, with export and publishing options.
• v0 by Vercel: interfaces and full-stack apps on Next.js, published to Vercel.
• Replit Agent: builds and publishes apps from a chat, with checkpoints and built-in databases.
• Lovable, compared with the others and with Claude Code in Lovable vs Claude Code.

The lesson from Spark applies to all of them: keep your code in a repository you control from the first week, so a product change is an inconvenience and not a loss.

A migration checklist

1. Find every spark you built and whether it has a repository.
2. For each one, check that the deployed app still loads and which features broke on July 30.
3. Clone the repository and get it running locally.
4. Search for llm() and choose a provider for each call.
5. List the hosting, data and sign-in the app relied on, and choose replacements.
6. Copy out any data users entered, if the app stored any.
7. Pick where you will build next, move the app, and retire the old one once the new one works.

Keeping the migration on a board

A few sparks turn into a surprising number of small jobs. In fenbs, paste the checklist into Add many to make one task per step and per app, then let your coding assistant work through them over MCP at https://fenbs.ai/api/mcp: the note says what broke and where, the plan says how it will be fixed, and the test status records what was actually checked. Tasks move through To Do, Next Up, In Progress and Completed, and History shows which assistant changed what. fenbs has no due dates or sprints, so if a deadline matters, write it in the note.