Skip to main content
A plugin repo is the plugin directory itself — manifest at the root, nothing to build server-side unless you ship a compiled runtime.

​
Repo layout

my-plugin/
├── myrax.plugin.toml     manifest at the root — required
├── README.md
├── docs/banner.png
├── web/
│   ├── plugin.js         [ui] entry
│   └── plugin.css
└── runtime/              optional backend
    └── server.js
Vendor your frontend dependencies (the Terminal plugin ships xterm.js in web/vendor/) — plugin assets are served by the panel, there is no npm step and no CDN at runtime.

​
Installing from a repo

Anyone can install straight from GitHub: 
myrax plugin install https://github.com/you/my-plugin
The panel clones the repo, reads the manifest, copies the plugin into /var/lib/myrax and remembers the source URL. From then on: 
myrax plugin update my-plugin   # re-installs from the same URL

​
Versioning

Bump version in the manifest on every release. It matters beyond display:
  • The panel serves plugin JS and CSS with a ?v=<version> query, so a bump invalidates browser caches — users get your new frontend without hard-refreshing.
  • myrax (e.g. ">=0.1.0") declares the minimum panel version you support.

​
Local development loop

myrax plugin install /path/to/my-plugin   # first install
# edit files...
myrax plugin update my-plugin             # re-install from the same path
myrax plugin logs my-plugin               # runtime output
myrax plugin restart my-plugin            # bounce the backend only

​
The built-in store

The store catalog is compiled into the panel (internal/plugins/store.go) — an entry maps a short name like terminal to its repo URL plus a description and tags. Adding a plugin to it is a pull request to Myrax; everything else installs by URL with no registration at all.