Architecture Discussion

[DevEpso]

As of right now Vault-Web consists of multiple services that each receive their own backend. Thereby we currently follow a Micro Services Architecture. Though a proper discussion for this is necessary, since it could make sense to move it all into the same Spring Boot Backend.

Which arguments support the monolithic structure for Vault-Web?

1. Easier to deploy, for the end user who may be non-technical it is easier to only start up a single backend.
2. Vertical Scaling, since Vault-Web is an open-source application for hosting your own cloud services, one has to assume that the user will host it on a single pc/server instance and doesn't care much about horizontal scaling and may rather upgrade their components.
3. Lower Ressourcen Overhead, micro services require different ports and CORS setup to communicate with each other.
4. Less latency, by avoiding http communication from service to service less latency for example through serialisation (JSON) can be achieved.
5. A central Authentication/Authorization system is handled centrally and doesn't require communication on the same instance between multiple ports.
6. No need for an api gateway.

I vote for a change of the architecture to a monolith one.

[DenizAltunkapan]

Thanks for summarizing the monolithic arguments @DevEpso — those are all valid points, especially from a deployment and user-friendliness perspective. However, I’d like to add a few thoughts on why a microservice-oriented (or at least modular) architecture might still be the better long-term choice for Vault-Web:

1. Security isolation:
   Vault-Web contains highly sensitive modules (e.g. the password manager), which ideally should not share a runtime, memory space, or database schema with other modules such as the chat or cloud file system. Separate backends provide natural isolation boundaries and make privilege escalation or data leaks between modules far less likely.

2. Independent service reliability:
   The services (cloud, password manager, chat) are designed to function even if another module is temporarily down. In a monolithic setup, a crash or dependency failure could affect the entire system.

3. Maintainability and modular growth:
   Each module (Vault Core, Cloud Page, Password Manager) can evolve independently — with different database structures, encryption requirements, or even frameworks if necessary. This keeps the codebase clean and manageable as the project grows.

4. Security layering and future extensions:
   For example, the password manager will likely require its own encryption flow and a master password system. Keeping it in a separate service allows implementing specialized JWT handling, encryption keys, and auditing logic without complicating the Vault-Core authentication system.

5. Deployment flexibility:
   While deployment might be slightly more complex, this can be mitigated with containerization (e.g. Docker Compose). The user still starts everything with a single docker-compose up, but we retain the architectural benefits of service separation.

6. Ease of introducing new services:
   A microservice architecture allows new modules (e.g. calendar integration, media server, or IoT dashboard) to be added independently without refactoring or redeploying the existing system. This makes it easier for contributors or third-party developers to extend Vault-Web in the future.

That said, I completely agree that for non-technical self-hosters, ease of deployment is important.
A hybrid approach could be ideal — one main Vault-Core backend (handling authentication, frontend, routing) that communicates with modular service containers internally. This keeps deployment simple while maintaining logical separation and layered security.

In short:
Monolith = easier setup;
Microservices = stronger modularity, security, and fault isolation.
Given Vault-Web’s focus on privacy, extensibility, and community-driven growth, I’d lean toward keeping a modular or hybrid architecture.

What is your opinion @MaximilianRau04 ?

[palukku]

1. Easier to deploy, for the end user who may be non-technical it is easier to only start up a single backend.

Could be easily done by building dockerfiles (or even better a compose file which starts every microservice separately) or other scripts to build either one executable or each by itself and connect it to each other "manually" using configuration files which can be overwritten by environment variables in the docker files for example.

3. Lower Ressourcen Overhead, micro services require different ports and CORS setup to communicate with each other.
4. Less latency, by avoiding http communication from service to service less latency for example through serialisation (JSON) can be achieved.

This point is kinda true when using normal http connections between the backend services, but could be designed using grpc which makes communication and overhead smaller due to better optimization because of the underlying protocol.

5. A central Authentication/Authorization system is handled centrally and doesn't require communication on the same instance between multiple ports.

A JWT could handle that by sending a jwt which includes all necessary informations it can be decoded using the private key and the permissions dont need to be fetched from the auth service, so only for refreshing the token etc. this endpoint is needed.

6. No need for an api gateway.

You mean like a "router" for routing the requests to the corresponding microservice?
So a kind of "balancer" between the services could be achieved by using a proxy (for example nginx or haproxy) which routes the traffic to the corresponding microservice by for example routing all /api/v1/password to the password microservice etc.

[DenizAltunkapan]

I suggest introducing a new repo for an API Gateway, which will handle all authentication for all our services. This way, we can centralize authentication and avoid having to change the security logic in every single repo.
Additionally, we can publish the complete portal as a container registry, so deployment becomes very easy — users would just run docker-compose up to start everything.

[MaximilianRau04]

I clearly consider a modular or hybrid approach to be the better choice for Vault-Web:

• The project focuses on data security and privacy, which argues against a pure monolith, since any security flaw could compromise the entire system.
• Microservices don’t have to be complicated when using Docker Compose. for the end user, it still feels like starting a single application.
• An API Gateway allows for centralized authentication in a clean and maintainable way, without having to duplicate security logic across codebases.
• Long-term maintainability and extensibility are essential as Vault-Web grows as a project.