Jugg backend
Jugg can connect to an HTTP backend for centralized plugin upgrades, hot updates, project defaults, usage events, and remote-machine applications. A backend is not required to run Jugg. Local features such as incremental compilation, deployment, CLI, and MCP remain available without one. When a backend is available, both manual reports and automatic failure-log uploads go to it; without one, automatic uploads are skipped.
Public builds from GitHub Releases and JetBrains Marketplace do not include a predefined server list. A fresh public installation without backend configuration does not connect to a backend automatically. Teams can use buildPluginInternal to bundle a server list. After an internal build that supports configuration inheritance runs, the IDE remembers that list. Upgrading to a public build then retains the internal defaults, including automatic server selection and backend connections. The list is stored in global IDE settings, so cleaning a project's build directory or opening another project does not remove it. An explicitly configured Custom Server takes priority; clearing it to restore defaults returns to the remembered list.
Configuration inheritance requires running an internal build that supports this behavior at least once. An older installation that has already switched to a public build without retaining a server list cannot recover it automatically from a historical address alone. Available backends continue to receive events and original diagnostic logs according to existing settings. Without an available backend, users can still choose to upload a redacted diagnostic bundle to the public service.
These pages are for teams that need to self-host a backend. They explain which backend features the plugin currently supports, which interfaces form a minimal implementation, and which features are optional enhancements.
Feature overview
| Feature | Purpose | Required when self-hosting |
|---|---|---|
| Update check | Tell the plugin whether a new full plugin package is available and optionally display a notification | Recommended |
| Project configuration distribution | Distribute server lists, compilation rules, module configuration, and custom compilers by project | As needed |
| Event reporting | Record results of compilation, deployment, update checks, and other actions | Optional |
| Hot update | Download JAR-level plugin updates and request restart or reinstallation when necessary | Optional |
| Custom compiler distribution | Distribute a team's custom compiler JAR to specified projects | As needed |
| Remote-machine application | Guide users through applying for a remote build machine in the IDE and fill in the configuration | Optional; usually depends on an internal platform |
Plugin-side call model
Android Studio starts or the user checks for updates
-> Jugg asks the backend for version and project configuration
-> The backend returns a notification, upgrade entry point, and customConfigJson
-> The plugin applies project defaults
Everyday compilation and deployment
-> The plugin reports events as needed
Hot-update check
-> The backend returns the target version, update notes, and a list of JAR files
-> The plugin downloads missing files and verifies their md5 values
-> The result tells the user to continue, restart the IDE, or reinstallRecommended reading order
- Self-hosting checklist: Implement the minimum viable backend first.
- Project configuration distribution: Maintain Jugg defaults by project.
- Plugin distribution and hot updates: Provide full plugin package downloads or hot updates.
- Diagnostics reporting: Collect usage events.
- Remote-machine application: Integrate with an internal cloud development machine application flow.