Vite Configuration
UsecreatePluginConfig() from the SDK:
vite option accepts any Vite config to merge in: plugins, resolve aliases, CSS config, etc.
If you only have a UI module, omit the background field.
Build Scripts
With background module:cross-env for Windows compatibility with the BUILD_TARGET environment variable.
How the Build Works
UI build (default): Compiles your React code into a single ESM bundle. Shared dependencies are externalised and resolved from the shell at runtime viawindow.__stratos_modules__.
The UI bundle is always one file: dynamic import()s are inlined rather than split into chunks, because Stratos can load ui/index.js from a blob: URL, where relative chunk imports can’t resolve. Don’t override build.rollupOptions.output to split it. process.env.NODE_ENV is replaced with the build mode (production for vite build) and any other process.env read is undefined, so libraries that check it work without a process shim. There is no Node process in the renderer.
Background build (BUILD_TARGET=background): Compiles your Node.js module into an ESM bundle. Electron, Node.js builtins, and the SDK are externalised.
CSS and Static Assets
Plugins are loaded at runtime viaimport(), so CSS and assets must be embedded in the JS bundle: separate files won’t be loaded.
CSS injection is handled automatically. Any CSS you import (including Tailwind output from @tailwindcss/vite) is injected into the DOM as a <style> tag when your plugin module loads. The shell wraps all plugin CSS in @layer plugin to prevent your styles from overriding the shell’s UI: you don’t need to do anything special for this.
Your plugin’s styles.css should include Tailwind and a @source directive so Tailwind can find your component files:
src/ui/styles.css
src:
.svg, .png, .jpg, .webp, .woff2, etc.).
What Gets Externalised
You do not need to bundle these: the shell provides them at runtime: UI externals:react,react-dom@tanstack/react-query,@tanstack/react-router@skyvexsoftware/stratos-sdksonner,socket.io-clientmaplibre-gl,react-map-gl/maplibre
electron@skyvexsoftware/stratos-sdk(except/helpers, which is bundled into your plugin)socket.io-client- All Node.js built-in modules
lucide-react, your own utilities) will be bundled into your plugin. Named lucide-react imports are tree-shaken, so only the icons you use are included. For icons chosen by name at runtime, use DynamicIcon from @skyvexsoftware/stratos-sdk/icons, which loads them from Stratos (core 2.49.0+) instead of bundling the whole set.
Build Output
Afterpnpm build, the dist/ directory contains:
ui/index.js: there are no separate .css files in the output.
Development Workflow
Live Reload Development
The recommended development workflow uses the Stratos app’s developer mode:- Open Stratos with the
--devflag - Sign in and select your airline
- In your plugin directory:
Manual Testing (No Dev Server)
If you prefer to test with a production build:- Run
pnpm build - Copy the
dist/contents to Stratos’s plugins directory:
- Restart Stratos: it discovers plugins by finding
plugin.jsonin each subdirectory.
dist/ directory to skip the copy step:
Deploying
Quick Deploy
The SDK includes astratos-deploy CLI that bundles and uploads your plugin in one step:
pnpm build, zips dist/ into bundle.zip (leaving out source maps), and uploads it to the Skyvex Software API. Your package.json should have:
create-stratos-plugin, this script is already included.
Add --release-mode=manual to stratos-deploy to hold an approved version until you press Release in the Developer centre.
Source maps are optional. Reviewers always read the bundle that runs, so a bundle without maps is reviewed as it is. If you do include maps (in your own zip or a Developer centre upload), build them in the same run as the bundle and keep sourcesContent: we check every map against the code it describes, and a map that doesn’t match holds the version for a closer look by a person. See Plugin review.
Authentication
Create an API token in the Developer centre at skyvexsoftware.com/developer/tokens (Developer centre → API tokens) and tick theplugin:upload scope.


plugin:upload scope. Uploads made with a token that lacks it are rejected with 403 Invalid scope(s) provided. Scopes are fixed when a token is created, so if your token doesn’t have it, create a new one with plugin:upload ticked and revoke the old one.
The plugin ID and version are read from plugin.json automatically. On success, the version goes to review, public or private, then the Skyvex Software server signs and publishes it to the CDN once it’s approved.
What’s new
Every version needs a What’s new before it goes to review: the reviewer reads it, and pilots see it with the update. It’s entered on Skyvex Software, never read from the bundle. Type it in the Developer centre when you publish, or send it with the upload. Withpnpm bundle, set SKYVEX_WHATS_NEW:
changelog form field alongside file.
An upload without one isn’t rejected. It waits as a draft in the Developer centre until you add a What’s new there and submit it, and you get an email saying so. The upload response’s status is draft, pending_review or approved.
Manual Upload
If you don’t have an API token or prefer to upload through the website:SKYVEX_API_TOKEN, the command still builds and creates bundle.zip: it just skips the upload and tells you where to upload manually at skyvexsoftware.com.
CI/CD
For automated deployments, setSKYVEX_API_TOKEN as a secret in your CI environment:
Full GitHub Actions Workflow
Drop this in your plugin repo at.github/workflows/deploy.yml for a complete deploy pipeline that builds the bundle and uploads it to Skyvex Software on every push to main:
.github/workflows/deploy.yml
- Add the workflow file at
.github/workflows/deploy.ymlin your plugin repo. - Generate an API token in the Developer centre under API tokens, with the
plugin:uploadscope ticked. - Add the secret in your GitHub repo: Settings → Secrets and variables → Actions → New repository secret. Name it
SKYVEX_API_TOKENand paste the token. - Bump
plugin.jsonversion before each push. An approved version can’t be replaced. - Push to
main(or trigger manually from the Actions tab). The workflow builds the bundle and uploads it for review; once it’s approved, the Skyvex Software API handles signing and CDN publishing.
README.md or unrelated files won’t trigger a deploy. Use workflow_dispatch to force a run from the Actions tab.
What Happens After Upload
- The Skyvex Software API checks your
plugin.json(snake_case keys only, no unknown keys, valid settings) - With a What’s new the version goes to review; without one it waits as a draft
- Once it’s approved and released, an
.integrityfile is generated with SHA256 hashes for every file in your bundle - The bundle is signed with Ed25519 and published to the CDN, and
latest.jsonis updated - Pilots receive the update automatically
Troubleshooting
Airline Plugin Sync
When a plugin has"type": "airline", the VA platform manages distribution. Stratos automatically syncs the plugin set on authentication:
- The pilot signs in to their airline
- Shell fetches the airline’s public plugin list (every plugin the VA has installed for everyone, plus core plugins)
- After relay-token authentication, the shell fetches the pilot-scoped list: this returns the airline-wide plugins plus any extras the VA admin has assigned to that specific pilot
- Missing plugins are downloaded and installed automatically; removed plugins are cleaned up
- Updates are applied automatically when new versions are published
"user" type plugins, pilots install them manually.