How to Publish a Figma Plugin: A First-Release Checklist

To learn how to publish a Figma plugin, finish and test the plugin in the Figma desktop app, verify its manifest and network scope, prepare an accurate Community listing, and submit it through Manage plugins for review. Test the real Figma runtime and unhappy paths before submission, because a plugin that works in an ordinary browser or development harness can still fail inside Figma. Plan support and updates before approval so the first release is maintainable.

Disclosure: ZeroRaised publishes this guide and appears in the final section. Figma controls its development, review and Community rules, which can change; the linked first-party pages were checked on 18 Oct 2026, and this guide makes no promise of approval, installs, traffic or sales.

TL;DR#

Publishing is a product-release job, not the last click after coding. Figma's current help material says classic plugins are developed and submitted from the desktop app, public Community plugins pass through review, and the creator is responsible for user support. Your release should therefore have four parts: a working package, realistic runtime tests, an honest listing and an operating plan.

The shortest useful sequence is:

1. Create or import the plugin in the desktop app and make a clean production build.
2. Audit manifest.json, especially editor support, entry files, dynamic page access, permissions and network access.
3. Run a test matrix in Figma with realistic files, account states and network failures.
4. Read the current review criteria and correct product, privacy, usability and listing problems.
5. Prepare the Community copy, images, support contact and set-up instructions.
6. Open Plugins > Manage plugins, choose Publish, complete each screen and submit for review.
7. Watch the account email used for Figma, respond to review feedback, and keep supporting the released build.

A 15 Oct 2026 reminder to test the real environment#

On 15 Oct 2026, developer Sangyoon Lee described a Figma plugin that read rows from a public Google Sheet. In “Figma plugin UI has a null origin: how I read a Google Sheet without a server or API key”, Lee wrote, “It looked easy: fetch the CSV, parse it, done.” The approach then met a cross-origin constraint in the plugin UI.

Lee tested different request paths in a sandboxed environment rather than assuming an ordinary web test represented the plugin. The most useful release lesson is Lee's exact conclusion: “Testing in the real environment saved me from shipping a plugin that fails on first load.” The source and its 15 Oct 2026 publication date were checked on 18 Oct 2026.

This is one maker's account of one integration, not evidence that every plugin will meet the same problem. It does show why the release boundary belongs inside Figma. Figma's own network request documentation says plugin iframes have a null origin, cross-origin rules apply, and calls from that context need an API that permits access from any origin. It also recommends specifying only the network domains the plugin needs (checked 18 Oct 2026).

The broader principle is simple: test the submitted architecture, not a convenient approximation. If the plugin has main code, an iframe UI, message passing, remote requests and file changes, each boundary belongs in the release test.

How to publish a Figma plugin from local build to review#

Start in the supported development route. Figma's guide to building classic Community plugins says users on any plan can develop them, but development and publication happen in the Figma desktop app, which is available for macOS and Windows. The same guide describes plugins as third-party scripts or applications that interact with Figma through the Plugin API (checked 18 Oct 2026).

That distinction matters for planning. The Community listing is not a web upload detached from the product. The desktop app reads the local development plugin, provides the Figma runtime in which you test it, and contains the publication path. Before thinking about screenshots or announcement copy, make the desktop build reproducible on a clean checkout.

Figma's Plugin API introduction says plugins extend Figma's editors, run in files and can use the API to read and write file contents. It also says the developer, rather than Figma, is responsible for supporting a third-party plugin and must supply a support contact at submission (checked 18 Oct 2026). Treat that support obligation as part of the product definition.

Write a one-page release brief before the final test:

• User: the specific person and editor context the plugin serves.
• Trigger: the file state, selection or command that starts the job.
• Result: the observable change or output a successful run produces.
• Boundaries: unsupported editors, node types, account states or file conditions.
• External services: every domain, account, API and payment the user encounters.
• Data: what the plugin reads, changes, sends or retains.
• Recovery: what a user sees when the operation cannot finish.
• Support: a monitored contact and the information needed to reproduce a fault.

Use the brief to keep code, manifest, listing and documentation aligned. If the listing says the plugin works in FigJam but editorType does not include it, that is a release defect. If the manifest permits every domain while the plugin contacts one API, that is unnecessary scope. If a screenshot shows a control removed from the production build, replace the screenshot.

Choose a development setup you can reproduce#

Figma's plugin quickstart uses the desktop app, TypeScript and Visual Studio Code as its recommended setup, while making clear that JavaScript and other editors are possible. It creates a plugin through Plugins > Development > New plugin, installs project dependencies, compiles TypeScript to JavaScript and runs the result from the Development menu (checked 18 Oct 2026).

You do not need to copy that toolchain exactly. You do need a production command that another contributor, or you in three months, can repeat. Record the runtime and package-manager versions, keep generated files out of manual editing, fail the build on type or lint errors you have chosen to enforce, and inspect the actual files referenced by the manifest.

Do one clean release build after removing development assumptions. A plugin can appear healthy while a watch process serves a file that the packaged project no longer creates. Close the watch task, delete only reproducible build output, rebuild, reopen the development plugin and run the core flow again. Keep the source tag or archive that corresponds to what you submit.

Audit the manifest before you test the product#

Every plugin needs manifest.json. Figma's manifest reference says the file describes the plugin, identifies the JavaScript entry point, can identify UI files, controls which editors the plugin appears in, and declares fields such as document and network access. It also says documentAccess with dynamic-page is required for all new plugins (checked 18 Oct 2026).

Do not copy a manifest from an old sample and assume it expresses the current build. Read every top-level field and connect it to a product behaviour.

The purpose is consistency, not minimalism for its own sake. A plugin that genuinely needs several domains should declare them. A plugin that needs none should say so. The problem is a mismatch between what the package does, what the manifest permits and what the listing tells the user.

Keep development-only settings out of the public package. The manifest reference marks proposed API enablement as a development feature that does not work in published plugins. It also provides devAllowedDomains for local development servers. A production flow that silently depends on either should fail your release gate.

Test the two execution contexts, not one abstract app#

Figma's How Plugins Run explains that plugin main code runs in a minimal JavaScript sandbox on the main thread. That sandbox can access the Figma scene but does not directly expose browser facilities such as the DOM or fetch. A UI created with figma.showUI() runs in an iframe that can use browser APIs but cannot directly access the Figma scene; the two sides communicate through messages (checked 18 Oct 2026).

That model creates explicit seams where faults can hide:

The runtime guide says a completed plugin must call figma.closePlugin(); otherwise it can continue running and leave a running notification until the user closes the tab. Test closure after success and after handled failure. Do not use closure to hide an error before the user can read it.

Use Figma's developer console guidance to inspect logs and API objects. The page also warns that the Developer VM has different performance characteristics from the normal sandbox and recommends final verification without it because its results can be unrealistic (checked 18 Oct 2026). The console is a diagnostic instrument, not the environment definition.

Run the final matrix with the production configuration and ordinary sandbox. Where a test needs fixture files, keep small named files for each condition: empty, ordinary, large, missing-resource and malformed-input cases. Record expected product behaviour rather than merely “does not crash”. A useful failure result might be a specific message, no unintended file change, retained user input and a safe retry.

Restrict and verify network access#

List every outbound request made by code and UI, including API calls, images, fonts, telemetry, authentication, payment checks and redirects. Separate what is necessary for the user-facing job from development convenience. Then express the necessary production scope in networkAccess.

Figma's network guide recommends beginning the restriction test with allowedDomains set to none, running the plugin, observing content security policy errors, and adding only the required domains. It says the plugin blocks calls to domains outside the list and shows the allowed-domain list on the Community page. If * is used, a reason is required and visible with the network scope (checked 18 Oct 2026).

Use the narrowest stable scope the integration permits. A precise path may be suitable for a fixed endpoint; a domain may be more honest when an API uses several routes or redirects. Test redirects from the first response to the last. Lee's Google Sheets account is relevant here because a successful final destination did not make the original request route work from the plugin UI.

Test these states for every required service:

1. Expected response with representative data.
2. Slow response and a user cancellation during the wait.
3. Offline or unreachable service.
4. Authentication missing, expired or rejected.
5. Permission denied for the requested resource.
6. Rate limit or temporary server failure where the service exposes one.
7. Malformed, empty or unexpectedly large response.
8. Redirect to an allowed or disallowed host.
9. Repeated command while the first request is pending.
10. Partial work followed by failure, with confirmation that the Figma file remains coherent.

Never place a secret in plugin code or the UI bundle and call it protected because it is not displayed. Anything shipped to the client must be treated as inspectable. If a service requires a confidential credential, design an appropriate server-side exchange and explain the data route accurately in your privacy and listing material.

Test the second 80 per cent before review#

The Figma developer page on publishing readiness calls the happy path the first 80 per cent of the work and asks creators to consider another set of cases: empty or wrong selections, multiple nodes, components and instances, missing fonts, offline use, deleted node references, multiplayer changes, rotation, large documents and bundle size (checked 18 Oct 2026).

Turn those prompts into a release matrix suited to your plugin. Not every row applies, but every omitted row should have a reason.

Also check accessibility and basic interaction quality: keyboard order, visible focus, readable status, sufficient contrast, clear labels and errors that identify the field or action. Test at narrow and enlarged UI sizes if the interface can resize. Do not communicate only through colour or a transient toast.

Ask one person who did not build the feature to follow the listing and instructions from a fresh file. Watch where they infer a different selection, editor, account or outcome. Fix the product or wording rather than coaching around the mismatch.

Prepare an accurate Community listing#

Figma's classic-plugin publishing instructions set out the current submission flow and fields. The Describe your resource step asks for a name, short tagline, description and category. The images step asks for an icon and thumbnail, and can include a playground file plus up to nine carousel images or videos. The final details include the publishing identity, support contact, network-access review and optional contributors (checked 18 Oct 2026).

Prepare the material outside the modal so it can be checked together:

• Name: distinctive, readable and consistent with the in-product title.
• Tagline: one user, one job and no unsupported superlative.
• Description: what the plugin changes or produces, how to start, what it needs and where its limits begin.
• Category: the closest current Community category, chosen for the job rather than hoped-for reach.
• Icon: recognisable at small size and not confused with Figma or another product.
• Thumbnail: the core result or workflow, with text that remains legible when reduced.
• Carousel: a truthful sequence from starting state to result, including set-up where it affects use.
• Playground file: a safe, representative way to try the plugin if a sample file genuinely helps.
• Support contact: an address or help route that is monitored and can receive reproduction detail.
• Documentation: current set-up, use, limitations, data handling and troubleshooting.

Figma currently recommends 128 by 128 pixels for the icon and 1920 by 1080 pixels for the image or video thumbnail on that help page. Treat those as current platform guidance, not universal design ratios. Inspect the result in the actual modal and listing preview.

Make external requirements conspicuous. If the plugin needs a third-party account, paid licence, API key or separate service, state that before the user invests time. If a free path has limits, name them. If a network call sends file content or user input elsewhere, the description and privacy material must explain the real route in language a user can understand.

Review the review guidelines as a product checklist#

Figma's plugin and widget review guidelines say the criteria are evolving and not exhaustive. Before submission, the page asks creators to test a range of scenarios, provide a support route, understand the relevant developer, creator, licensing and Community terms, and prepare necessary legal material such as a privacy policy with appropriate advice (checked 18 Oct 2026).

The guidelines group review around quality and usability, trust and safety, business, and legal concerns. Convert those broad areas into questions you can answer with the build and listing:

Do not treat review as a guessing game about wording. If the product surprises the reviewer because it changes more of a file than the listing suggests, repair the behaviour or explanation. If the tool is intended only for an internal group, use the appropriate private organisation route rather than disguising it as a general Community product.

This article is not legal advice. The review page itself directs creators to understand their obligations and consult legal counsel. Your documents must match your actual product, service providers, users and jurisdictions.

Submit from the desktop app#

Once the production build, test evidence and listing material agree, use the desktop path in Figma's publishing help:

1. Create or open a file in the Figma desktop app.
2. Open the Figma menu and go to Plugins > Manage plugins.
3. Open the menu beside the intended plugin and select Publish.
4. Complete Describe your resource with the checked name, tagline, description and category.
5. Complete Choose some images with the icon, thumbnail and any useful playground or carousel material.
6. Complete any applicable data-security disclosure accurately.
7. Complete Add the final details, including publisher identity, support contact, network review and contributors.
8. Read the final preview against the submitted build.
9. Choose Publish to submit the plugin for review.

Enable two-factor authentication before publication; Figma lists it among the prerequisites on the publishing page. Confirm that the account email is current because Figma says it uses that address for the review decision. Do not predict an approval date: the help page says timing varies with submission volume and team availability.

If the submission is rejected, preserve the message, map each item to code, listing, policy or documentation work, and retest affected paths before submitting again. A rejection is not evidence that the whole product idea is invalid. It is specific review feedback against the current build and presentation.

Support the first release and publish carefully#

Approval changes distribution, not responsibility. Give the released version a tag or immutable source archive. Keep a short version note with shipped behaviour, known limits, manifest changes, service dependencies and the test matrix used. Store listing copy and images beside the release record so a later editor can see what users were promised.

For the first release, monitor:

• support messages grouped by reproducible symptom;
• crashes and handled failures you can lawfully and safely observe;
• external service changes and authentication failures;
• reviews or comments that identify a concrete mismatch;
• documentation steps that users repeatedly miss;
• the editors, modes and file states involved in faults.

Do not turn install counts or a handful of comments into a claim about product-market fit. One report may expose a serious destructive fault; ten vague compliments may produce no product decision. Prioritise severity, reproducibility and the number of affected workflows, then state what remains uncertain.

Before an update, repeat the checks affected by the change and a compact regression of the core path. Pay special attention to changes in permissions, domains, data use, pricing, authentication and core purpose. Update the listing and documentation when behaviour changes, not several versions later.

Use the product launch checklist for the wider release operation, including support, analytics, legal pages and rollback preparation. The bootstrapped app launch guide helps separate product readiness from distribution. If the plugin has an inspectable technical story, the Show HN writing guide explains that community's try-it-first expectations; never assume Community approval makes a promotional post suitable elsewhere.

After you have fixed early release faults, the free marketing channels guide can help you choose a small, relevant distribution test. Match every post to the destination's rules and make the Figma Community listing the accurate source of product facts.

Give a supportable plugin a second release surface#

A Figma Community listing is the required product home for this publishing path. A separate launch surface can tell the maker story, but it cannot replace Figma's review, installation route, documentation or support.

ZeroRaised is a launch board for eligible products with no institutional VC or accelerator equity. If your approved plugin has a public product page and fits the published eligibility rules, review the details and use the submission page. Submission is a review request, not a promise of traffic, installs, rank or sales.

The maker perks page is a separate resource for eligible makers and is not part of Figma's publishing process. Whether or not you use another release venue, the answer to how to publish a Figma plugin stays grounded in the product: build through the supported route, test inside Figma, declare access honestly, submit an accurate listing, respond to review, and support the version users install.