Publishing Plugins
This guide covers the process of signing, packaging, and publishing Grafana plugins to make them available to the community or within your organization.Plugin Signing
Grafana requires plugins to be signed to verify their authenticity and integrity. The signing process creates aMANIFEST.txt file that contains checksums of all plugin files.
Signature Levels
Grafana supports different signature levels:- Grafana: Official plugins developed by Grafana Labs
- Commercial: Commercial plugins from verified partners
- Community: Community plugins verified by Grafana
- Private: Private plugins for internal organizational use
- Private Glob: Private plugins with wildcard matching
Signature Status
When loading plugins, Grafana checks the signature status:internal: Core plugin, no signature required (e.g., built-in data sources)valid: Plugin signature is valid and content matchesinvalid: Signature verification failedmodified: Valid signature but plugin content has been modifiedunsigned: No signature file present
pkg/plugins/models.go:
Signing Your Plugin
Prerequisites
- Create a Grafana Cloud account: Required for plugin signing
- Generate an access policy token: From Grafana Cloud portal
- Install @grafana/sign-plugin: Plugin signing tool
Signing Process
- Build your plugin:
- Sign the plugin:
MANIFEST.txt file in your plugin directory.
- Verify the signature:
- Plugin metadata
- File checksums (SHA256)
- Signature information
- Timestamp
Private Plugins
For internal/private plugins, configure Grafana to allow unsigned plugins:Plugin Packaging
Directory Structure
A complete plugin package:Backend Binaries
For backend plugins, include binaries for all supported platforms:- Linux:
gpx_<plugin-id>_linux_amd64 - macOS (Intel):
gpx_<plugin-id>_darwin_amd64 - macOS (ARM):
gpx_<plugin-id>_darwin_arm64 - Windows:
gpx_<plugin-id>_windows_amd64.exe
Creating the Archive
Create a ZIP archive:- Be named
<plugin-id>-<version>.zip - Contain a single root directory with the plugin ID
- Include all necessary files and binaries
Publishing to Grafana Plugin Catalog
Requirements
- Open source license: Plugin must be open source (Apache 2.0, MIT, etc.)
- Public repository: Code hosted on GitHub, GitLab, or similar
- README.md: Comprehensive documentation
- CHANGELOG.md: Version history
- Valid signature: Plugin must be signed
- Working plugin: Thoroughly tested
Submission Process
- Create a release on GitHub:
- Attach the signed ZIP archive to the GitHub release
-
Submit to Grafana:
- Go to grafana.com/plugins
- Click “Submit a plugin”
- Fill out the submission form
- Provide plugin details and repository URL
-
Review process:
- Grafana team reviews the plugin
- May request changes or improvements
- Approval typically takes 1-2 weeks
-
Publication:
- Once approved, plugin appears in the catalog
- Available for installation via Grafana UI or CLI
Plugin Metadata
Ensureplugin.json has complete information:
Private Plugin Distribution
Internal Plugin Repository
For private/enterprise plugins, set up an internal repository:- Host plugin files on internal server or S3
- Configure plugin repository in Grafana:
- Serve plugin catalog JSON:
Manual Installation
For ad-hoc distribution:- Copy plugin to Grafana plugins directory:
- Restart Grafana:
- Verify installation:
Plugin Updates
Version Management
Follow semantic versioning (SemVer):- Major (1.0.0 → 2.0.0): Breaking changes
- Minor (1.0.0 → 1.1.0): New features, backward compatible
- Patch (1.0.0 → 1.0.1): Bug fixes
Update Process
- Update version in
package.jsonandplugin.json - Document changes in
CHANGELOG.md - Build and sign the new version
- Create GitHub release with new tag
- Update plugin catalog (automatic for published plugins)
Migration Handlers
Handle breaking changes with migration code:Plugin Installation
Users can install plugins via:Grafana UI
- Navigate to Configuration → Plugins
- Search for the plugin
- Click Install
Grafana CLI
Docker
Best Practices
Documentation
- Comprehensive README: Installation, configuration, usage examples
- Screenshots: Show query editor, config, and visualizations
- Changelog: Document all changes between versions
- License: Include appropriate open source license
- Contributing guidelines: If accepting contributions
Quality Assurance
- Test thoroughly: All features across Grafana versions
- Check compatibility: Test with minimum required Grafana version
- Performance: Optimize queries and rendering
- Error handling: Graceful degradation and error messages
- Security: Sanitize inputs, validate data
Versioning
- Follow SemVer: Major.Minor.Patch versioning
- Update CHANGELOG: Document all changes
- Tag releases: Use git tags for versions
- Backward compatibility: Avoid breaking changes when possible
- Deprecation warnings: Warn before removing features
Support
- Issue tracking: Use GitHub Issues or similar
- Community forum: Monitor Grafana community discussions
- Response time: Address critical bugs quickly
- Documentation updates: Keep docs current
Plugin Catalog Guidelines
Naming Conventions
- Plugin ID:
<org>-<name>-<type>(e.g.,acme-weather-datasource) - Display name: Clear, descriptive (e.g., “Weather Data Source”)
- No “Grafana” prefix (automatically implied)
Requirements
- Unique ID: No conflicts with existing plugins
- Quality code: Well-structured, maintainable
- Security: No vulnerabilities
- License compatibility: Open source license
- Branding: Respect Grafana trademarks
Rejections
Plugins may be rejected for:- Security vulnerabilities
- Malicious code
- Poor quality or broken functionality
- Trademark violations
- Duplicate of existing plugin
Monitoring Plugin Usage
Track plugin adoption:- Download statistics: Available in Grafana plugin catalog
- GitHub metrics: Stars, forks, issues
- Telemetry (optional): Anonymous usage statistics
- User feedback: Issues, discussions, reviews
Resources
- Sign a plugin guide
- Publish a plugin guide
- Plugin catalog
- grafana-cli documentation
- Source:
pkg/plugins/manager/signature/for signature validation logic