Jugg backend self-hosting checklist
Self-hosting usually serves two goals: centrally distributing Jugg configuration and plugin versions within a team, or collecting usage events and providing hot updates and remote-machine applications. Implement the minimum interfaces first, then add enhanced features gradually.
Minimum viable interfaces
| Interface | Method | Minimum behavior |
|---|---|---|
/check_update | GET | Return the current latest version, whether an upgrade is required, a download entry point, notifications, and project configuration |
/report_event | POST | Accept event JSON and return 2xx on success |
/check_hot_update | GET | Return an empty update result when hot updates are unused |
If only project configuration distribution is required, /check_update can return isNeedUpgrade=false and place project configuration in customConfigJson. Other interfaces can return success or an empty result.
When a backend is available, both manual reports and automatic failure-log uploads request its /report_issue, so the backend must implement this endpoint. Explicitly configured Custom Servers and backends selected from either the current bundled list or a remembered internal list receive original logs, which may contain project paths, usernames, and other sensitive content. After an internal build that supports configuration inheritance runs, a public upgrade can still connect to the internal backend. A fresh public installation without backend configuration does not use this path by default. Use a trusted server and prefer HTTPS. Without an available backend, manual reports upload a redacted bundle to the public service while automatic uploads are skipped. See Report an issue.
/check_update response
| Field | Description |
|---|---|
latestVersion | Latest full plugin version according to the backend |
isNeedUpgrade | Whether to ask the user to download and install a full plugin package |
downloadUrl | Full plugin package download page or URL |
templateList | Legacy field; can currently return an empty array |
notification | Optional notification displayed by the plugin in the IDE |
customConfigJson | Optional project configuration applied by the plugin to the current project |
customConfigJson is the most commonly used self-hosted backend feature. It can return different configuration by project name. See Project configuration distribution.
Optional enhanced interfaces
| Feature | Related interfaces | When to add it |
|---|---|---|
| Full plugin package download | /download_page, /download | Publish plugin packages centrally from the internal backend |
| Hot-update download | /check_hot_update, /download_hot_update | Distribute JAR-level updates |
| Hot-update status | /check_hot_update_status | Operations or staged-rollout diagnostics need to inspect current hot-update state |
| Custom compiler download | /download_custom_compiler | Distribute a custom compiler JAR in project configuration |
| Manual issue reports and automatic failure logs | /report_issue | Receive manual diagnostic bundles and automatic failure-log bundles |
| Remote-machine application | Interactive interfaces such as /remote_apply | The team has an internal cloud development machine application system |
Predeployment checks
- The backend domain must be reachable from development machines with Jugg installed.
- Download links for plugin packages, hot-update JARs, and custom compiler JARs must support direct downloads.
- When
md5is returned, it must match the file content. - When using a database, store at least the event time, user identity, project, version, action, and result.
- For unused features, return empty configuration or an empty update instead of 500.
Relationship to local features
The backend does not take over local compilation or deployment; when available, it can also receive manual issue reports. Jugg Run, Debug, Android Test, CLI, and MCP still execute in the local Android Studio or command-line environment.