# Vibma froze its own development and shipped a tunnel-only Dockerfile

> Vibma is an MCP server that let agents build Figma files, and its readme now says development has stopped. What sits in the tree afterwards says more than the feature list ever did: a marketplace rejection, a container image that runs one tunnel, and eleven markdown files at the root.

**ufira-ai/Vibma** — Vibe Design meets Figma. Let AI agents design directly in Figma.

- Repository: https://github.com/ufira-ai/Vibma
- Stars: 625 · Forks: 34
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/ufira-ai-vibma

## Vibma stopped itself, and the tree still looks like a release

Vibma is no longer under active development, and the reason sits in a status block at the top of the readme: Figma has shipped native MCP capabilities for agents, and the Vibma plugin was turned down for the marketplace on grounds of overlap with that first-party offering. The notice also says plainly that Vibma is not an official Figma tool, and it points readers at Figma's own integration for production work. That framing is unusual. Most abandoned plugins leave a stale readme and a directory full of drift; this one leads with its own obituary and then keeps publishing scripts. The last push was 8 June 2026, which is more recent than the version numbers suggest: v1.1.5 shipped on 19 May, and v1.1.3 a month earlier on 19 April. The repository is not archived. It holds 627 stars, 34 forks, and 34 open issues. So the code is frozen by choice rather than by neglect.

## Setup points an agent at a raw CARRYME.md URL

Vibma splits its instructions three ways and gives two of them names that read like typos. DRAGME.md is the path for cloning the repository and building from source. CARRYME.md is the path for installing from npm without cloning. A generated documentation site covers tool parameters, response schemas, and examples. The table is tidy enough. The hand-off to an agent is where it gets strange, because the readme offers a two-line prompt to paste into any assistant:

```
Set up Vibma so I can vibe-design in Figma.
Follow the instructions at https://raw.githubusercontent.com/ufira-ai/vibma/refs/heads/main/CARRYME.md
```

That URL resolves to a raw markdown file on the main branch. There is no version in it, no checksum, and no tag, so whatever CARRYME.md says today is what the agent will act on tomorrow, and a silent edit to that one file changes what every pasting assistant builds. The root is crowded too: markdown files for readers, for agents, and for Chinese-speaking readers of both, plus AGENTS.md and CLAUDE.md aimed at different assistants, with nothing indexing them.

## Three credentials sit under a heading that says two

The optional integrations section claims all core tools work without API keys, then says two optional integrations add library discovery and stock photos. The table underneath lists three environment variables. FIGMA_API_TOKEN unlocks published team library components and styles. FIGMA_TEAM_ID sets the default team for that discovery. PEXELS_API_KEY covers searching and placing stock photos. Two of the three belong to the library feature and one to images, so the number in the sentence may be counting capabilities rather than variables. The practical cost shows up a few lines down: the Figma personal access token needs two scopes, file content read and team library content read, and a token issued with only the first will fail at library lookup rather than at connection time. FIGMA_TEAM_ID is not optional in the useful sense either, because it is the number in a figma.com files URL, and without it the library search has no team to search. The readme does not say which error either failure produces.

## The model table names no date and misspells its own price claim

Model choice is presented as a decision the reader has to get right, so the table carries weight it has not earned. Two tiers are offered: a baseline row pairing GPT 5.2 Medium, Claude Sonnet 4.6, Gemini 2.5 Flash, and Kimi K2.5, and a recommended row pairing GPT 5.4, Claude Opus 4.6, Gemini 3.1 Pro, and Kimi K2.6. Nothing in that table carries a date, a release note, or a source. GPT 5.4 is called the best balance of tool competence and design taste. Claude Opus 4.6 gets strongest tool use, paired with the warning that finished designs can feel formulaic. Gemini 3.1 Pro is a solid middle ground that GPT 5.4 currently edges on both axes. The final line recommends Kimi K2.6 for following harness instructions and calls it probably the cheapeast model that delivers a good experience overall, misspelling cheapest in the one sentence carrying the cost claim. A reader is left to guess whether the rankings came from internal use, vendor pages, or nothing at all.

## One runtime dependency, and two scripts that run the same line

The runtime dependency list of the root package has one entry: yaml at 2.8.2. Everything else is a development dependency, including typescript at 5.9.3, tsx at 4.21.0, globals at 17.5.0, and eslint at 10.2.1. That last version deserves a second look, because typescript-eslint sits at 8.59.0 in the same block. A TypeScript-aware lint layer a full major behind the linter it plugs into is either pinned for a reason or simply not updated. The script table carries its own duplicate: codegen and docs:generate both run tsx schema/compiler/index.ts, character for character, with no flag to tell them apart. docs:dev and docs:build then chain that compiler before handing off to the docs directory, so one file generates both whatever schema the tools expose and the site that explains them. Two names for one command is not harmful by itself, but it leaves no way to regenerate one artifact without the other from the script layer alone.

## build covers three workspaces and build:watch covers two

The root package declares workspaces as packages/* and then splits its build across three of them. npm run build chains packages/core, packages/adapter-figma, and packages/tunnel in that order, so a fresh clone compiles the tunnel last and nothing serves until the Figma adapter is done. The watch variant drops packages/tunnel entirely and joins the other two with an ampersand, which on a shell without job control can leave one half of the watch quietly attached to the terminal. The start script is node dist/mcp.js, a path at the repository root, while all three build outputs land inside their own package directories. No script in the table copies those outputs up into a root dist, so start depends on an arrangement the readme leaves unstated. Two further entries reach for shell files instead, setup and release, both under scripts/, and neither file is part of what this repository exposes.

## The Dockerfile ships the tunnel and nothing else

The container image is nine lines long and contains one workspace. It starts from node:18-slim, copies packages/tunnel/package*.json, runs npm install --production, moves a prebuilt packages/tunnel/dist/index.js to /app/index.js, exposes 3055, and runs node index.js.

```
FROM node:18-slim

WORKDIR /app

COPY packages/tunnel/package*.json ./

RUN npm install --production

COPY packages/tunnel/dist/index.js ./index.js

EXPOSE 3055

CMD ["node", "index.js"]
```

No source is copied and no build step runs, so the image works only against a tunnel directory compiled beforehand, and TypeScript never enters the container. The production flag strips development dependencies, which means tsx is gone, so the socket script cannot be the entry point inside it. What the image starts is the tunnel bundle, not the MCP server the start script reaches through node dist/mcp.js, and this repository does not record what listens on 3055 or how a client is meant to arrive there. Reading this file as the packaging story for Vibma mistakes one component for the whole.

## plan.md and TODO.md outlived the work they planned

Eleven markdown files sit at the repository root, and two of them are planning documents: plan.md and TODO.md. They live in the same tree as the stop notice, and neither the readme nor the status block says what happens to them. The repository also keeps AGENTS.md and CLAUDE.md for different assistants, alongside templates/, schema/, assets/, and docs/ directories, plus a generated schema compiler under schema/. None of that changes what the code does, but it changes how the project should be read. A codebase that froze deliberately leaves its plan behind for a successor to compare against, and that is the useful case here: the readme's own framing of learning and reference under MIT makes the design decisions the deliverable rather than the running server. The 34 open issues are the part of that story with no answer, since nothing recorded in the repository says whether anyone will read them.

## Conclusion

Vibma is worth reading for the Figma MCP plumbing it already worked out, and it is not worth wiring into anything new: the project declares itself no longer under active development, points production users at Figma's own integration, and last pushed on 8 June 2026. Before trusting any of it, check what your agent actually does with a raw CARRYME.md URL that can change without a release, and confirm that the tunnel image on port 3055 does what your client expects, because the repository does not say.

## FAQ

### Is Vibma still under active development?

No. The readme states that Vibma is no longer under active development, calls itself not an official Figma tool, and points production users at Figma's native MCP integration. The last push to the repository was 8 June 2026.

### Why was the Vibma plugin not accepted to the Figma marketplace?

The readme gives a single reason: overlap with Figma's first-party MCP offering, announced through Figma for Agents. It gives no date, no category, and no message from the marketplace itself.

### What environment variables does Vibma need for its optional integrations?

Three: FIGMA_API_TOKEN for discovering published team library components and styles, FIGMA_TEAM_ID as the default team for that search, and PEXELS_API_KEY for stock photos. All core tools are said to work without any key.

### Which language models does Vibma recommend for design work?

A recommended tier of GPT 5.4, Claude Opus 4.6, Gemini 3.1 Pro, and Kimi K2.6, over a baseline of GPT 5.2 Medium, Claude Sonnet 4.6, Gemini 2.5 Flash, and Kimi K2.5. No dates or sources are attached to that table.

### What does the Vibma Dockerfile actually build?

Only the tunnel. It copies packages/tunnel/package*.json, installs production dependencies, moves a prebuilt packages/tunnel/dist/index.js to /app/index.js, and exposes port 3055. No source is copied and no compilation happens inside the image.

## Sources

- [Issues](https://github.com/ufira-ai/Vibma/issues)
- [License: MIT](https://github.com/ufira-ai/Vibma/blob/main/LICENSE)
- [README](https://github.com/ufira-ai/Vibma/blob/main/README.md)
- [Releases](https://github.com/ufira-ai/Vibma/releases)
- [ufira-ai/Vibma on GitHub](https://github.com/ufira-ai/Vibma)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ufira-ai-vibma