The digest proves file identity
A matching SHA-256 shows that the downloaded bytes match the package whose digest you entered. It catches corruption and unexpected replacement between publication and installation.
Three plugin boundaries
Not every plugin has the same job
Community plugins
Community extensions use the normal plugin manifest and declare the community feature. They can add integrations or operator-specific workflows and may load on the FREE tier.
Payment providers
Payment integrations implement the provider contract used to create invoices and confirm settlement. They must never grant service because a customer returned to a success URL. Access changes only after provider-confirmed settlement.
Commercial plugins
Paid capabilities use the same discovery model but require a feature present in the signed license. The repository contains the integration boundary while protected commercial implementation is delivered through the licensed release pipeline.
ManifestName, version, author, description, and required license feature
BackendRoutes and service hooks mounted under a plugin-owned namespace
FrontendOptional lazy-loaded components for operator settings and controls
EntitlementCommunity access or a signed paid feature checked at runtime
Install by URL
What the panel verifies and what it cannot verify
The admin panel accepts a versioned .tar.gz URL and a published SHA-256 digest. It downloads the package, checks the digest, applies archive safety limits, and installs into the plugin directory.
The digest does not prove good intent
A harmful package can have a perfectly valid digest. Review the source, publisher, requested configuration, outbound connections, and data access before trusting it.
Archive checks limit packaging attacks
The installer rejects path traversal and oversized archive entries so a package cannot simply write arbitrary files outside its installation boundary through crafted paths.
Runtime permissions still matter
A backend plugin runs inside the application environment. Treat it like server code, not a browser theme. Back up first and test on a non-production installation.
Operator checklist
Review before you install
- Use a versioned release URL rather than a branch archive that can change
- Compare the SHA-256 against a digest published through a separate trusted page
- Read the manifest and source, especially code handling payments, customers, secrets, or outbound requests
- Confirm the plugin namespace does not replace core authentication or license checks
- Create a current backup and test installation, restart, update, and uninstall behavior away from production
- Record the plugin version so the environment can be reproduced during recovery
Flirexa does not currently operate a public plugin marketplace. A package appearing in a repository is not an endorsement by Flirexa.
For developers
Keep the extension small and explicit
A good plugin owns a narrow responsibility, declares its feature requirement, uses namespaced routes, and does not phone home without the operator's explicit consent.
Declare the boundary
Use a clear manifest, a stable route prefix, and documented environment variables. Avoid hidden dependencies on private operator state.
Fail closed where money is involved
Payment callbacks need signature verification, idempotency, amount and currency checks, and provider settlement before access is granted.
Publish reproducibly
Tag releases, attach the exact archive, publish its digest, document migrations, and explain how to roll back.