Deployment Model
The Alien Intelligence platform supports two deployment modes: Alien Hosted (the default, fully managed experience) and On-Premise (for enterprises that need physical control of their data infrastructure). Both modes use the same architecture and codebase — the difference is where data clusters run and who manages them.
Two Deployment Modes
Alien Hosted (Default)
In the Alien Hosted model, Alien manages everything: the platform, all data clusters, and the underlying infrastructure. This is the default for most customers.
| Aspect | What You Get |
|---|---|
| Platform services | Managed by Alien — backend, workers, MCP servers, identity provider |
| Data clusters | Managed by Alien — provisioned automatically when you create a cluster |
| Infrastructure | Kubernetes, databases, storage, search engines — all managed |
| Networking | Internal — platform and data clusters communicate within Alien's infrastructure |
| Updates | Automatic — new features and security patches deployed continuously |
| Scaling | Automatic — resources scale with your usage |
| Monitoring | Alien monitors health, connectivity, and performance |
Who this is for: Most teams. You get full platform capabilities without managing any infrastructure.
On-Premise (Enterprise)
In the On-Premise model, Alien manages the platform, but data clusters run on your infrastructure — your own data center, your cloud account, or any Kubernetes environment you control.
| Aspect | What You Get |
|---|---|
| Platform services | Managed by Alien — same as Alien Hosted |
| Data clusters | Managed by you — deployed on your Kubernetes infrastructure |
| Infrastructure | You provide Kubernetes; Alien provides Helm charts and automation |
| Networking | Skupper mTLS tunnels — outbound-only from your side, no inbound firewall rules |
| Updates | Helm chart updates provided by Alien; you control when to apply them |
| Scaling | You control cluster sizing; autoscaling configured via Helm values |
| Monitoring | You monitor your infrastructure; platform monitors connectivity via heartbeats |
Who this is for: Enterprises with strict data residency requirements, regulatory constraints (GDPR, HIPAA), or organizational policies that require physical control of data storage.
What Alien Manages in Each Mode
| Component | Alien Hosted | On-Premise |
|---|---|---|
| Platform backend (API, auth, billing) | Alien | Alien |
| Workers (AI workflow execution) | Alien | Alien |
| Frontend (web dashboard) | Alien | Alien |
| MCP servers (AI agent access) | Alien | Alien |
| Identity provider (SSO) | Alien | Alien |
| Data cluster operator | Alien | You (with Alien's Helm charts) |
| PostgreSQL (tenant databases) | Alien | You |
| MinIO (object storage) | Alien | You |
| Qdrant (vector database) | Alien | You |
| Meilisearch (keyword search) | Alien | You |
| Argo Workflows (document pipelines) | Alien | You |
| Skupper (cross-cluster networking) | Alien | You (outbound connection only) |
| Kubernetes cluster | Alien | You |
In On-Premise mode, "managed by you" means you maintain the Kubernetes cluster and apply Helm chart updates provided by Alien. The data cluster operator automates most internal operations — tenant provisioning, credential management, and infrastructure reconciliation happen automatically once the operator is running.
Platform Architecture
Regardless of deployment mode, the platform follows the same architecture:
Platform (always Alien-managed): Handles user authentication, billing, job scheduling, the dataset catalog (metadata pointers only), workflow execution, and MCP-based AI agent access. The platform never stores customer document data.
Data Clusters (Alien-managed or On-Premise): Store and process all customer data — documents, embeddings, vector indexes, full-text indexes, and processed files. Each tenant gets an isolated namespace with dedicated databases, storage, and search engines.
The platform communicates with data clusters through an authenticated proxy layer. All requests are logged and scoped to the requesting user's permissions. See Architecture Overview for the full component map.
Environment Strategy
The platform uses three environments for progressive deployment:
| Environment | Purpose | Deployment |
|---|---|---|
| Development | Internal testing and feature development | Automatic on code push |
| Staging | Pre-production validation with real-world configurations | Automatic on merge to staging branch |
| Production | Customer-facing workloads | Deployed after staging validation |
Each environment has its own platform deployment with isolated databases, secrets, and configuration. Staging mirrors production configuration as closely as possible to catch issues before they reach customers.
For On-Premise data clusters, you control your own environment strategy. Most enterprises run a single production data cluster, but you can deploy staging and production clusters independently if needed.
How Updates Work
Alien Hosted
Updates are automatic and continuous:
- Code changes pass through CI (automated testing, security scanning, linting)
- New container images are built and pushed to the registry
- ArgoCD (the GitOps deployment tool) detects the new image
- Rolling deployments update services with zero downtime
- If a deployment fails health checks, it automatically rolls back
You do not need to take any action for updates. New features, performance improvements, and security patches are deployed as they are ready.
On-Premise
Updates follow a controlled release process:
- Alien publishes updated Helm charts with release notes
- You review the changes and decide when to apply them
- You update the chart version in your ArgoCD configuration (or run
helm upgrade) - ArgoCD applies the changes to your data cluster
- The data cluster operator handles any necessary migrations
On-Premise data clusters report their current chart versions to the platform via heartbeats. If your cluster is running an outdated version, the platform dashboard will indicate that an update is available.
Availability and SLA
Alien Hosted
The platform is deployed on managed Kubernetes with:
- High-availability databases — PostgreSQL runs with multiple replicas and automatic failover
- Autoscaling — workers and API services scale based on load
- Rolling deployments — updates happen without downtime
- Health monitoring — every data cluster sends heartbeats; degraded clusters are flagged automatically
- GitOps-managed infrastructure — all configuration is versioned and auditable
On-Premise
Availability depends on your infrastructure, but the architecture supports high availability:
- PostgreSQL HA — CloudNativePG supports multi-replica configurations with automatic failover
- Qdrant replication — vector database runs as a replicated StatefulSet
- MinIO erasure coding — object storage survives disk failures
- Data API autoscaling — horizontal pod autoscaler adjusts replicas based on CPU
- Independent operation — if the connection to the platform is interrupted, your data cluster continues serving local reads and writes. Pipeline processing and search continue to work. When connectivity is restored, metadata syncs automatically.
Decision Matrix
Use this matrix to decide which deployment mode fits your organization:
| Consideration | Alien Hosted | On-Premise |
|---|---|---|
| Time to value | Minutes — create account and start | Days to weeks — requires Kubernetes expertise |
| Infrastructure team needed | No | Yes — you need a team to manage Kubernetes |
| Data residency control | Data stored in Alien's infrastructure | Data stored on your infrastructure |
| Regulatory compliance | Suitable for most requirements — data isolation is enforced at the architecture level | Maximum compliance — physical data sovereignty |
| Update control | Automatic — always on latest version | You control when to update |
| Cost model | SaaS subscription — infrastructure included | SaaS subscription + your infrastructure costs |
| Scaling control | Automatic | You configure scaling parameters |
| Network requirements | Internet access to the platform | Outbound HTTPS to the platform (no inbound rules) |
You can start with Alien Hosted and migrate to On-Premise later. The platform is designed so that data clusters can be added or moved without affecting the platform configuration. Contact us to discuss migration planning.
Next Steps
- Architecture Overview — The full platform component map
- Networking — How the platform and data clusters communicate
- Infrastructure — Per-cluster infrastructure components
- Data Sovereignty — How data isolation is enforced
- Create a Data Plane — Set up an On-Premise data plane