Sharing your micro-apps with /create-canvas in the GitHub Copilot app

One of the first things I see people do when you hand them an AI coding agent is build what I call "micro-apps": small applications that solve one specific problem they're having. A colleague of mine built a tool that scans our servers for outdated configurations so we could follow up on the migration process. Another built his own planning tool to support the yearly planning cycle.

The code itself takes an agent minutes to produce. The problem shows up right after. The app still needs to be hosted somewhere. That's typically the point where non-technical people get stuck. They don't have a place to deploy a small web app, they don't want to manage a server for something this small, and asking IT to provision infrastructure for a five-minute tool feels disproportionate.

This is where the canvas feature in the GitHub Copilot app comes in. Using the /create-canvas slash command, you can turn a conversation with Copilot straight into an interactive interface, and share or host it through the app itself. No separate deployment step.

What a canvas actually is

A canvas is a shared, interactive surface that lives inside the GitHub Copilot app. Think of it as a work artifact: a triage board, a dashboard, a checklist, a small planning tool. The agent builds it based on your prompt, and it opens directly in the app's right-side panel.

Remark: the important part here is "shared". A canvas is bidirectional. The agent can update it while it works, and you can click, edit, and interact with the same surface. Your actions can go back to the agent or be handled locally by the canvas itself.

That's a different model than the usual chat loop of "ask a question, get a wall of text back". For things like reviewing a backlog or tracking migration progress, a visual surface is simply a better fit than scrolling through a conversation.

Creating a canvas

You create a canvas from within an agent session using the /create-canvas command, followed by a description of what you want:

/create-canvas Create an interface that allows me to easily swipe through issues in a repo in card format. Can swipe right to ship, left to reject.

Copilot builds the interface and opens it in the side panel. From there you keep iterating in plain language: ask it to add a filter, change a layout, or expose a new action, and the canvas evolves alongside your workflow.

A few examples of what people have built with it:

• An interactive diagram of how services in a codebase relate to each other, with hover and filter support.
• A worktree view showing which Copilot sessions are still active and which are orphaned, with one-click cleanup.
• A knowledge finder that searches Slack, Teams, email, and docs to surface who has context on a given file.

Going back to my colleague's config-scanning tool: instead of a script that dumps results to a terminal, /create-canvas turns that into a small dashboard non-technical stakeholders can actually open and click through.

Where hosting actually happens

This is the part that solves the original problem. When you create a canvas, you choose a scope:

• Project scope — .github/extensions, committed to the repository. Anyone with access to that repo can open the canvas from their own Copilot app.
• User scope — ~/.copilot/extensions, kept local to your machine.

Tip: for the yearly-planning-tool scenario, project scope is what you want. Commit it once, and the whole team gets it through the Copilot app without anyone touching a deployment pipeline.

Under the hood, a canvas extension is a small, ordinary-looking package:

• package.json for metadata and dependencies.
• An entry file, typically extension.mjs, defining the canvas's behavior and capabilities.
• An optional artifacts directory for persisted state.

Nothing exotic. It's the packaging and the fact that it opens inside the Copilot app, on both the author's and every teammate's machine, that removes the hosting question entirely.

Opening an existing canvas

You don't need to build a canvas from scratch every time. Some are delivered through plugins, and once installed they show up as ready-made canvases you can just open.

1. In the app sidebar, click Customize.
2. Click Canvas.
3. Browse the featured canvases.
4. If a canvas requires a plugin, click Install plugin.
5. Click New session to open a session with the canvas.

For example, installing the Azure DevOps plugin gives you a canvas for planning and managing Azure DevOps work, no /create-canvas prompt needed.

This same view also lists everything already committed to .github/extensions in a repo you have access to, under Installed. So if a colleague already built and shared the config-scanning dashboard from earlier, you don't recreate it. You open a session on the repo and pick it up from there.

You can also open an available extension by clicking on the + icon and choosing Canvas from the menu:

Putting it together

So, the workflow for a micro-app looks like this:

1. Describe the problem to Copilot and let it build the logic, same as before.
2. Run /create-canvas, describing the interface and the actions people should be able to take on it.
3. Pick project scope if it needs to be shared, user scope if it's just for you.
4. Commit it, and your colleagues open it straight from their own Copilot app.

That's it. The tool exists, it's usable by people who don't want to know what a deployment is, and nobody had to spin up a server for it.

More information

• How to build interactive experiences with canvases
• Working with canvas extensions in the GitHub Copilot app (docs)
• A guide to slash commands in the GitHub Copilot app