Plugin & Theme system for community-driven customization

[MaxenceMahieux]

Summary

I'd like to suggest adding two extensibility features to Coolify that would allow the community to customize and extend the platform to better fit their specific needs.

Proposed features

1. Plugin system

Allow the community to create, share, and install custom plugins. This would let users extend Coolify's functionality without requiring changes to the core codebase, for example: custom deployment targets, integrations with third-party services, additional monitoring tools, or workflow automations.

2. Theme support

Add a theming system so users can customize the look and feel of their Coolify instance. This is especially valuable for agencies or teams hosting client-facing dashboards who want to match their own branding.

Why this matters

• Community-driven growth: a plugin ecosystem lowers the barrier for contributions and lets Coolify grow faster than core maintainers alone could push it.
• Personalization: every team has slightly different needs, plugins/themes let users tailor Coolify without forking it.
• Reduced core bloat: niche features can live as plugins instead of being merged into core.

Thanks for considering!

[Kunal-ninthquadrant]

I highly agree with you on this.
Plugins and theme support would be "nice to have's"

[MaxenceMahieux]

Yes I think ...
I would be a very interesting feature and this would make Coolify even more efficient because it could be optimized for everyone !

[Resetnak]

I've built a first version of this against next and would like to open a PR if the scope suits you.

Short version: a Settings → Theme page for self-hosted instances. An instance admin picks one of eight bundled dark palettes (Catppuccin, Dracula, Gruvbox, Nord, One Dark, Rosé Pine, Solarized, Tokyo Night), or picks "Custom CSS" and pastes their own. Pasting an iTerm2 .itermcolors file works too. It gets converted to a theme on save. The resulting CSS is inlined after app.css for everyone on the instance.

What I deliberately kept it to:

• Themes only override the semantic variables the UI already reads (--color-app, --color-panel, --color-accent, ...). No component classes touched, no token refactor.
• Everything is scoped to html.dark. Light appearance stays stock.
• Two nullable columns on instance_settings. Presets are plain CSS files in resources/themes/, no build step.
• Instance admins only. isCloud() can hide the page entirely if you want this self-hosted only.
• There's an optional file route too (/data/coolify/themes/custom.css → /custom-theme.css) for people who'd rather skip the UI. Easy to drop if you'd prefer a single path.

Not in scope: theme upload, a marketplace, per-team themes, light-mode presets, any kind of plugin system.

Pest tests cover the presets, the iTerm2 conversion, inlining, save/validation and the file route. Screenshots and a fuller writeup will go in the PR itself.

Would you take a PR at this scope? If it's easier to review, I'm fine trimming it to UI only or file only.