OpenCloud embeds security in the architecture. From the code base to the network structure and data storage, the platform follows a clear principle: maintain control, reduce attack surfaces and avoid dependencies.

1. Isolated components as the basis of the architecture

With OpenCloud, security does not start with individual protection functions, but with the architecture. The platform follows a clearly structured three-tier architecture model: The web front end, application layer and storage layer are strictly separated from each other and communicate exclusively via defined interfaces. OpenCloud consistently encrypts all connections between services and tiers with TLS - both internally and externally.

All incoming requests first pass through an upstream proxy, which acts as an API gateway. Routing, authentication and TLS termination are bundled here. Unauthorised or incorrect requests do not even reach the application layer, but are intercepted beforehand.

Modular microservices work in the application layer, each isolated in their own containers. Each service takes on a clearly defined task. Any errors or security problems are therefore limited to the affected component. Updates or adjustments to individual services do not automatically affect the overall system.

The storage level manages files and metadata via the file system and connected object storage, optionally with SSE-C encryption. The event broker NATS handles the exchange of messages between the application and storage. Communication is asynchronous. Processes do not block each other - security-relevant functions remain stable even under load.

2. Compiled code and signed containers

A key difference to classic file management systems lies in the way the code is executed. OpenCloud is developed entirely in Go, a compiled programming language that does not require an interpreter and runs directly on the machine. This reduces the attack surface: there is no interpreter that reprocesses the source code for every request and no possibility of uncontrolled reloading of scripts at runtime.

The platform consists of several containerised microservices. The development team builds each component as a separate image and provides it with a cryptographic signature before publication. Image integrity is checked before productive use. Only authentic and unmodified containers go live.

With OpenCloud, changes are always made via the defined build and signature process. This also applies to extensions. Plugins are possible - but they are not directly connected to the core system. They run in their own processes and only communicate with the core via clearly defined APIs. This is a decisive difference to classic, interpreter-based systems in which extensions are executed in the same process space as the core system. If a plugin crashes there, it takes everything with it in case of doubt. With OpenCloud, the line is clearly drawn. Even if an extension is faulty, this does not automatically affect the core.

And importantly: extensions are created as independent components and undergo the same controlled build and signature process as all other services. Extensibility does not mean loss of control. The result is a reproducible deployment with clearly traceable versions - without the typical risks of dynamically expandable web applications.

3. Network security and protected infrastructure operation

OpenCloud fits into existing infrastructures without enforcing a specific network architecture. Organisations operate the platform in their own data centre, in a private cloud or completely isolated in an air-gap environment.

A permanent connection to external cloud services is not required. Data remains under the control of the operating organisation. There is no technical need to transfer information to external providers.

The upstream proxy or API gateway controls incoming connections centrally and integrates the platform into existing security concepts.

4. Identity management and role-based access control

OpenCloud does not introduce isolated user management, but integrates into existing systems. The platform supports OIDC, OAuth2 and SAML and connects to LDAP, Active Directory or Keycloak. External identity providers authenticate users. OpenCloud takes over the confirmed identities and controls authorisation based on them. Authentication and access control remain clearly separated.

The authorisation model follows the principle of least privilege. Administrators assign rights consciously and based on roles. Administrative tasks, content responsibility and operational use remain separate. In this way, the platform prevents the unintentional, creeping expansion of authorisations.

OpenCloud logs security-related events in a traceable manner. Organisations can document access and implement their internal governance and compliance requirements.

5. Malware protection and controlled file uploads

File uploads are one of the most common attack vectors. OpenCloud treats them accordingly.

The platform supports the connection of a malware scanner via ICAP (Internet Content Adaptation Protocol). Uploaded files undergo a check before they are processed or released. The application does not rely solely on file extensions. It takes the actual file content into account and thus prevents manipulated files from remaining undetected due to renaming.

The protection mechanisms at a glance:

• Integration of a malware scanner via ICAP
• Scanning of files in the upload process
• Content-based file scanning instead of pure extension checking

With this approach, OpenCloud treats file uploads as a security-relevant process and integrates existing protection measures into the platform.

6. Data storage without a relational SQL database

OpenCloud deliberately dispenses with a relational SQL database. The platform stores files and metadata in the file system or object storage.

This eliminates the need for an additional database instance with its own schemas, migrations and interfaces. The architecture remains manageable. At the same time, there are no SQL-based attack surfaces. OpenCloud does not execute SQL queries and does not expose a corresponding database interface.

Backups are performed at the file system or connected object storage level. Snapshot-based backups do not require a separate database export. The storage logic remains consistent and clearly traceable.

7. Scalable services and stable load distribution

OpenCloud's architecture is designed for predictable resource utilisation and controlled scaling. As individual services work separately, organisations scale the component that requires additional resources as the load increases. They do not replicate the entire system, but react precisely to real requirements.

The absence of a central relational database prevents a classic bottleneck. Metadata accesses are not bundled in a single instance. The event broker also decouples processes. Load peaks in one area do not automatically block other components.

Technical features with regard to availability:

• Separate service instances instead of monolithic architecture
• Scaling of individual components as required
• No central SQL database as a bottleneck
• Decoupled communication via NATS

Availability with OpenCloud is a consequence of the architecture - not an additional function that is added later.

8. Data protection, compliance and digital sovereignty

Security is not just a question of technology. Organisations also need regulatory clarity and control over their data.

OpenCloud runs entirely under the control of the operating organisation. The platform is operated in its own data centre or in a private cloud. The storage location, network access and data flows therefore remain transparent and controllable. Organisations retain sovereignty over personal information and integrate the platform seamlessly into their existing data protection and governance structures.

Open standards and documented interfaces create transparency instead of dependency. At the same time, traceable protocols enable integration into existing audit and reporting processes.

Digital sovereignty is not a buzzword with OpenCloud, but a direct consequence of the architecture: controllable operation, clear responsibilities and no enforced external ties.

Conclusion

Those who need to fulfil demanding security and compliance requirements need solutions that do not have to be assembled first. OpenCloud delivers exactly that: a platform that thinks security before it implements it.

OpenCloud shows that modern file sharing is possible without relinquishing control. No hidden dependencies, no forced cloud connections, no unnecessary complexity. Instead: clear architecture, controllable operation and traceable responsibilities.