[GH-ISSUE #1424] Ability to Virtualize Multiple Instances / Multi-Tenancy Support #1001

New issue

Open

opened 2026-05-07 00:29:28 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-07 00:29:28 +02:00

Owner

Originally created by @SamGreenwood1 on GitHub (Aug 16, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1424

💡 Idea
The core idea is to introduce the ability to virtualize or "multi-tenant" multiple distinct ntfy instances on a single ntfy server installation. Currently, a single ntfy server installation operates as one logical instance with a shared configuration, database, and topics. This feature would allow administrators to define and manage multiple isolated "virtual instances," each with its own:

Configuration: Separate ntfy.yml (or similar) files, allowing different base URLs, retention policies, authentication methods, default topics, etc.
Database/State: Independent persistence for topics, messages, and user data. This ensures that one virtual instance's data doesn't mix with another's.
Authentication/Authorization: Dedicated user management and permissions, meaning users from one virtual instance cannot access or publish to topics on another.
API/Web Interface: Potentially accessed via distinct URLs, supporting various configurations such as:
- Subdomains on a single base domain (e.g., instance1.yourcompany.com, instance2.yourcompany.com)
- Subdomains across different top-level domains (e.g., ntfy.clientA.com, alerts.clientB.org)
- Subpaths on a single domain (e.g., yourntfydomain.com/instance1/, yourntfydomain.com/instance2/)

Use Cases:

Multi-Tenancy: ISPs or hosting providers could offer ntfy as a service to multiple independent clients, each getting their own isolated notification system without deploying separate VMs. This is particularly powerful with support for client-specific domains/subdomains.
Departmental Isolation: Large organizations could provide dedicated ntfy instances for different departments (e.g., IT, HR, Marketing), each with its own specific configurations, users, and topics, all running on one central server.
Personal Projects: A user could isolate personal notification systems for various projects or environments (e.g., "home automation," "development server," "production alerts") within a single ntfy installation.
Resource Efficiency: Reduce the overhead of running multiple full ntfy server instances in separate containers or VMs when logical separation is sufficient.

This feature would significantly enhance ntfy's utility in shared environments and enterprise settings by providing strong isolation while leveraging a single underlying server deployment.

💻 Target components
This feature would primarily be implemented in the ntfy server. It would involve changes to:

Server-side architecture for managing multiple configurations and databases.
API routing to direct requests to the correct virtual instance based on hostname or path.
Potentially a new administrative interface or CLI commands to create, manage, and monitor virtual instances.

Originally created by @SamGreenwood1 on GitHub (Aug 16, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1424 :bulb: **Idea** The core idea is to introduce the ability to virtualize or "multi-tenant" multiple distinct ntfy instances on a single ntfy server installation. Currently, a single ntfy server installation operates as one logical instance with a shared configuration, database, and topics. This feature would allow administrators to define and manage multiple isolated "virtual instances," each with its own: * **Configuration**: Separate `ntfy.yml` (or similar) files, allowing different base URLs, retention policies, authentication methods, default topics, etc. * **Database/State**: Independent persistence for topics, messages, and user data. This ensures that one virtual instance's data doesn't mix with another's. * **Authentication/Authorization**: Dedicated user management and permissions, meaning users from one virtual instance cannot access or publish to topics on another. * **API/Web Interface**: Potentially accessed via distinct URLs, supporting various configurations such as: * Subdomains on a single base domain (e.g., `instance1.yourcompany.com`, `instance2.yourcompany.com`) * Subdomains across different top-level domains (e.g., `ntfy.clientA.com`, `alerts.clientB.org`) * Subpaths on a single domain (e.g., `yourntfydomain.com/instance1/`, `yourntfydomain.com/instance2/`) **Use Cases**: * **Multi-Tenancy**: ISPs or hosting providers could offer ntfy as a service to multiple independent clients, each getting their own isolated notification system without deploying separate VMs. This is particularly powerful with support for client-specific domains/subdomains. * **Departmental Isolation**: Large organizations could provide dedicated ntfy instances for different departments (e.g., IT, HR, Marketing), each with its own specific configurations, users, and topics, all running on one central server. * **Personal Projects**: A user could isolate personal notification systems for various projects or environments (e.g., "home automation," "development server," "production alerts") within a single ntfy installation. * **Resource Efficiency**: Reduce the overhead of running multiple full ntfy server instances in separate containers or VMs when logical separation is sufficient. This feature would significantly enhance ntfy's utility in shared environments and enterprise settings by providing strong isolation while leveraging a single underlying server deployment. :computer: **Target components** This feature would primarily be implemented in the **ntfy server**. It would involve changes to: * Server-side architecture for managing multiple configurations and databases. * API routing to direct requests to the correct virtual instance based on hostname or path. * Potentially a new administrative interface or CLI commands to create, manage, and monitor virtual instances.