Planelets: Instant Plug-n-Play Integrations#5094
Open
ThatXliner wants to merge 25 commits into
Open
Conversation
PODMAN-SPECIFIC FIX. The dev compose stack failed to start under
Podman: `links` is unsupported ("link is not supported"), and the
`/tmp:/tmp` bind-mount inherited Podman rootless UID mapping so
container root could not write to /tmp, breaking `go build`.
Drop the deprecated/redundant `links` (compose DNS already resolves
services by name), drop the /tmp bind-mount (container gets its own
writable /tmp), and add `init: true` so tini reaps orphaned watcher
processes. All harmless under Docker.
PODMAN-SPECIFIC FIX. `make dev.server` launches the entrypoint via `compose exec -d`. Under Podman, when the detached exec session leader exits, the whole exec process group is SIGKILLed — so air, vite, and the Go server they spawn die the moment the script returns, leaving the app unreachable (502 from the Go proxy to a dead Vite). Run each watcher under `setsid` so it lives in its own session and survives the exec teardown. Redirect output to /app/tmp logs since the detached session has no terminal. Harmless under Docker.
The SDK example installs a copy of the plugin-sdk into sdk/example/node_modules, which itself contains example/node_modules — an infinite recursive directory loop. Air walked it forever and never built the server. The existing `node_modules` exclude only matches the top level, not this nested path; exclude `sdk` outright since it is TypeScript, not Go.
The plugin concept is branded "Planelets" in the canvas UI. Align the backend so identifiers match the product name: package, directory, registry key, integration type name, and the node IDs/event types emitted on the wire (plugin.onEvent -> planelet.onEvent, etc.). Safe to change the wire identifiers now since nothing uses the integration yet — no existing canvases reference the old IDs.
Match the "Planelets" product branding used in the canvas UI and the renamed backend integration. Renames the npm package (@superplane/plugin-sdk -> @superplane/planelet-sdk), the public API (createPlugin -> createPlanelet, PluginServer -> PlaneletServer, PluginOptions -> PlaneletOptions), and the example that consumes it.
Follow the package and integration rename so the docs reference the current @superplane/planelet-sdk API and "Planelets" canvas labels.
The example installs the SDK via `file:../`, which recreates the parent (including example/node_modules) inside the install tree — an infinite nesting that must never be committed.
feat: add Planelet API
|
👋 Commands for maintainers:
|
superplane-policy-bot
Bot
requested review from
andrecalil,
forestileao,
lucaspin and
shiroyasha
Author
|
Note that |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For the 2026 SuperPlane Hackathon: Team EZDev
Summary
This PR introduces Planelets, a plugin system that lets anyone extend SuperPlane with custom integrations. A Planelet is a standalone HTTP server, built with a TypeScript SDK (or in any of the other languages we implemented), that exposes a manifest describing its actions, triggers, and configuration fields.
SuperPlane discovers these capabilities at runtime and renders them natively in the workflow canvas, meaning plugin-provided components look and behave identically to built-in ones. Instantly.
What's included
Backend integration (~1,600 lines of Go in
pkg/integrations/planelet/):RunActionexecutor that resolves dynamic configuration schemas from the manifest and dispatches to the plugin serverOnEventtrigger supporting webhook-style event ingestion from plugin serversplanelet_test.goDevEx and tooling:
Feel free to modify/restore/undo these changes. It was just necessary for me to use on my own local setup
air/Vite processes on container reuse.dockerignoreto keep build context leanDesign decisions worth noting
How to test
make dev.up && make dev.setup && make dev.serverhttps://planelet.vercel.app/weather)TODO post-Hackathon