🔐Security and compliance
When deploying a Private Instance of Ellipsis Drive, security responsibilities are shared between Ellipsis Drive and your organisation.
In an Ellipsis Drive-hosted Private Instance, infrastructure security and platform hardening are handled by Ellipsis Drive.
In a self-hosted deployment, your organisation is responsible for configuring and maintaining all infrastructure-level security controls according to internal policies.
The following sections describe key security-relevant aspects of an Ellipsis Drive deployment. Each section reflects the minimum required configuration. We recommend applying the principle of least privilege across all components.
Root access
Ellipsis Drive components are designed to run in Docker-based environments.
Root access is required only during initial deployment and setup within containers
No persistent root access is required after deployment
Host-level root access is not required for normal operation
Networking
Only API-facing components require access to the public internet for normal operation.
Public access enables optional capabilities such as automated updates.
All internal services must be able to communicate with each other. Deployment within a virtual private cloud environment (for example AWS VPC or equivalent) is strongly recommended.
Subnet-level segmentation is optional and depends on internal security requirements.
If no external storage system is used, Ellipsis Drive-managed storage remains isolated and accessible only through the platform.
SSH and system access
System access is managed at the infrastructure level.
Direct access to containers is performed via host-level administration
Separate SSH access per container is not required
Access control policies for host systems are determined by your organisation’s infrastructure setup.
Secrets and credentials
By default, application credentials are stored in deployment configuration files to ensure portability across environments.
A configuration utility is available to:
update credentials across all nodes
rotate secrets across the system
For enterprise environments, we strongly recommend using a dedicated secrets management system such as AWS Secrets Manager or equivalent.
Sensitive data protection
User data is stored in multiple stages:
Temporary ingestion storage
Passive (persistent) storage
Active processing storage
Encryption of data at rest and in transit is supported and should be configured according to your organisation’s security standards.
Backups are not handled automatically by the application layer. Backup policies must be implemented at infrastructure level.
At minimum, passive storage should be included in backup strategies. Active storage can be rebuilt from passive storage if required.
User authentication
Users authenticate using email or username combined with a password.
Best practice includes enforcing regular password updates and password policies according to organisational standards.
User email addresses are not exposed to other users. Only usernames are visible within the system.
Last updated