What is apm-studio/apm-studio?

APM Studio imports, edits, runs and exports Agent Package Manager primitives from a local browser UI. The interesting part is not the editor but the boundary it draws: Studio owns the workspace, Microsoft APM owns validation and target installs.

Can I use apm-studio/apm-studio commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is apm-studio/apm-studio still maintained?

Yes. The repository last received commits 105 days ago.

What programming language is apm-studio/apm-studio written in?

Mainly TypeScript, according to GitHub's language statistics.

APM Studio: local GUI for APM packages

At a glance

What is it?: APM Studio imports, edits, runs and exports Agent Package Manager primitives from a local browser UI. The interesting part is not the editor but the boundary it draws: Studio owns the workspace, Microsoft APM owns validation and target installs.
Who is it for?: Adopt APM Studio if you keep APM packages in a repo and want to see detected primitives before installing them, or if you need to test a Studio Agent with model settings that never reach the exported assistant files. Skip it if you want a hosted editor, or if you expect Studio alone to install into every assistant target: the README states target sync is CLI-first and the Studio-native fallback covers only supported agent and skill sync.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 105 days ago.
What is it written in?: Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 16, 2026 · apm-studio/apm-studio

The gap APM Studio fills between a package repo and five assistant configs

Agent Package Manager gives you a package format for agents, skills, prompts, hooks and MCP configs. What it does not give you is a way to look at what a GitHub source actually contains before you pull it into a workspace, or a place to keep local runtime settings that should not ship to anyone else. APM Studio is aimed at that gap. The README describes it as a local GUI that imports source references from GitHub, manages local packages under packages/*, runs Studio Agents with local runtime settings, and exports selected primitives into assistant target files when you choose to sync. The audience is narrow and specific: someone who already keeps APM packages in a repository and wants a visual layer over the same files, not a replacement for them. If you never touch apm.yml, the tool has nothing to show you.

Import, manage, run, export: the four-step flow and where files land

The README lays the flow out as a four-row table: import, manage, run, export. Import searches source references or takes a pasted GitHub repo, previews the detected primitives and installs the selected packages locally. Manage edits local package metadata and Studio Agent composition while canonical package content stays under packages/<packageId>/. Run tests Studio Agents with Studio-only model settings. Export syncs selected agents, instructions, skills, prompts, commands, hooks or MCP configs into supported assistant targets.

The file layout is the part worth reading twice. Source and output are deliberately separated, and the README draws it as a pipeline:

text

GitHub source -> packages/<packageId>/apm.yml -> Studio Agent runtime
                                             -> Export target sync -> assistant files

Studio-only workspace state lives in .apm-studio/, and the generated OpenCode runtime projection lives in .opencode/. Assistant target files are written only through Export. That last sentence is the design commitment: editing in the UI does not silently rewrite your Codex or Claude configuration. You have to ask for it. For anyone who has watched a tool overwrite a hand-tuned config file, that is the right default, and it is also the reason nothing appears in your assistant until you press the export path.

Installing APM Studio and running a first import

The README lists four requirements: Node.js >=20.19.0, macOS, Linux, Windows or WSL, OpenCode for the local Studio Agent runtime, and the Microsoft APM CLI for full target sync coverage. Note that OpenCode is a requirement, not an optional extra. Without it, the Run step has no runtime.

On Unix, the documented installer is a shell script piped to sh. Adding --start launches Studio when installation finishes.

bash

curl -fsSL https://raw.githubusercontent.com/apm-studio/apm-studio/main/public/install.sh | sh
curl -fsSL https://raw.githubusercontent.com/apm-studio/apm-studio/main/public/install.sh | sh -s -- --start

On Windows the equivalent is a PowerShell one-liner, with -Start for the immediate launch:

powershell

irm https://raw.githubusercontent.com/apm-studio/apm-studio/main/public/install.ps1 | iex
iex "& { $(irm https://raw.githubusercontent.com/apm-studio/apm-studio/main/public/install.ps1) } -Start"

The README states that the installer installs or updates apm-studio, checks for the upstream Microsoft APM CLI, delegates missing APM CLI setup to Microsoft APM, and runs apm install when the current workspace already has an apm.yml. It prints the concrete start command when it finishes. If you prefer npm, the manual route is two commands:

bash

npm install -g apm-studio
apm-studio

The CLI accepts a path and options. The README's examples include opening a specific project, suppressing the browser, changing the port, and running diagnostics:

bash

apm-studio ~/projects/my-app
apm-studio open . --no-open
apm-studio open . --port 43111
apm-studio doctor

The published CLI app and API listen on port 43100 by default, and the managed OpenCode sidecar on 43102. Development uses 43200, 43201 and 43202. After the server is up, the flow is: paste a GitHub repo or search a source reference, preview the detected primitives, select packages, install them locally, then edit metadata under packages/<packageId>/. Running apm-studio doctor first is the cheap way to find out whether your environment is complete.

Target sync is CLI-first, and the fallback is narrower than the promise

This is the limitation to understand before you install. The README states that target sync is CLI-first: Studio tries APM_STUDIO_APM_CLI, then apm, then uvx --from git+https://github.com/microsoft/apm.git apm. Studio-native fallback is limited to supported agent and skill sync when no CLI runner is available.

Read that as a hard boundary. If none of the three runners resolves, you do not get a degraded version of full sync. You get agent and skill sync only. Instructions, prompts, commands, hooks and MCP configs are not covered by the fallback, so a workspace without the Microsoft APM CLI can look like it is exporting while several primitive types never leave the machine. The README does not document a preflight check that tells you which runner was selected, so the practical way to confirm coverage is to check that apm resolves in the same shell where you launched Studio, or set APM_STUDIO_APM_CLI explicitly. The uvx path exists as a third option, which suggests the project expects users who do not have the CLI on PATH, but it also means sync behaviour can differ between two machines running the same Studio version.

Where Studio stops and Microsoft APM starts

APM Studio is not a reimplementation of the package format. The README calls it the visual layer for the upstream Microsoft APM package format and CLI, and lists microsoft/apm and microsoft.github.io/apm as the upstream references. The division of labour is explicit: Studio keeps package authoring, local Studio Agent runs and assistant target sync in one UI, while package validation and broad target installs are delegated to Microsoft APM.

That is a sensible split, and it is also a dependency you are accepting. Studio's correctness for validation and install behaviour tracks whatever the upstream CLI does, and the three-runner resolution order means your effective behaviour is partly determined by your machine rather than by the Studio version alone. The Studio-only model settings are the counterweight: those stay local and are not emitted to target assistant files, which is the one place Studio deliberately holds state that the upstream toolchain does not see.

The alternative: driving the Microsoft APM CLI directly

The obvious alternative is the Microsoft APM CLI itself, with apm.yml files edited by hand and installed by command. The difference is not capability, since Studio delegates validation and broad target installs to that same CLI. The difference is where the work happens. The CLI gives you a text-only loop: you read apm.yml, you run the install, you inspect the resulting assistant files with whatever diff tool you already use. It is scriptable, reviewable in a pull request, and has no runtime requirements beyond the CLI itself.

Studio trades that for a preview step and a local runtime. You see detected primitives before installing them, you edit package metadata and Studio Agent composition in a UI, and you test agents with local model settings that never reach the exported files. The cost is a Node.js >=20.19.0 runtime, an OpenCode runtime for Run, a local server on 43100, workspace state in .apm-studio/, and generated artifacts in .opencode/. If your workflow is already a Makefile and a CI job, the CLI alone is the smaller surface. If you are choosing packages from GitHub and want to know what is inside them first, Studio is doing work the CLI does not attempt.

Licence, release cadence and the cost of keeping up

APM Studio is MIT licensed, and the package.json lists the author as monarchjuno. MIT is permissive, so the usual obligations apply: keep the copyright notice and the licence text with any redistribution. That is a statement about the licence file, not advice about your situation.

On maintenance, the repository is not archived, and the last push was on 2026-06-03. Three releases are listed in the recent history: v0.3.5 on 2026-06-03, v0.3.2 on 2026-06-02, and v0.2.12 on 2026-05-21. The README's development section describes the release check as type-check, test, pack:check, then npm publish --dry-run, and notes that publishing a fix requires a new npm version so that npm install -g apm-studio and the installers' default latest tag can receive it. That is a deliberate release discipline rather than a rolling branch, and it means upgrade cost is a version bump plus whatever the upstream Microsoft APM CLI changed underneath you. The README points to doc/DEPLOYMENT_GUIDE.md for release gates, installer flow, npm latest verification and a deployed install smoke test, but does not document a rollback path. If you pin a version, verify the sync behaviour after each upgrade rather than assuming the previous export still holds.

Editorial conclusion

Adopt APM Studio if you keep APM packages in a repo and want to see detected primitives before installing them, or if you need to test a Studio Agent with model settings that never reach the exported assistant files. Skip it if you want a hosted editor, or if you expect Studio alone to install into every assistant target: the README states target sync is CLI-first and the Studio-native fallback covers only supported agent and skill sync. Before committing, run apm-studio doctor in the workspace and confirm which of APM_STUDIO_APM_CLI, apm or uvx resolves on your machine, because that determines whether export works at all.

Frequently asked questions

What is APM Studio used for?

It is a local GUI for Agent Package Manager packages. The README describes importing source references from GitHub or pasting a repo, managing local packages under packages/*, running Studio Agents with local runtime settings, and exporting selected primitives into assistant target files.

What does APM stand for in APM Studio?

The README expands it as Agent Package Manager, the upstream Microsoft package format and CLI that Studio builds on. Studio delegates package validation and broad target installs to that CLI.

What does APM mean when working with APM Studio?

In this project the term refers to the Agent Package Manager format, where each package lives at packages/<packageId>/apm.yml and contains primitives such as agents, instructions, skills, prompts, commands, hooks and MCP configs.

What does APM stand for in marketing, and does that apply to APM Studio?

The material only covers the Agent Package Manager meaning used by APM Studio, so it cannot answer the marketing sense of the abbreviation. Within this project, APM refers to the Microsoft Agent Package Manager format and CLI.

Official sources

Community notes