> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Managed Deployment on Your Kubernetes Cluster > AgentEye Managed Deployment on Your Kubernetes Cluster documentation. AgentEye is a self-hosted observability and evaluation platform for AI and LLM agents. It captures agent sessions, tool calls, model requests, and errors, turns them into searchable analytics and evaluations, and surfaces the results in a dashboard with an optional read-only AI assistant. In the managed deployment model, you provide a dedicated Kubernetes cluster and Exosphere runs the full platform inside it, deploying, configuring, operating, backing up, and upgrading every component on your behalf. Your team gets the platform's value (agent visibility, analytics, evaluation, and the optional assistant) without operating databases, certificates, or upgrades. All data stays within your cloud account. *** ## Prerequisites * A **GitHub PAT** for pulling container images and downloading artifacts (see [enterprise-docs/github-token.md](/agenteye/github-token)) * A **dedicated Kubernetes cluster** (see requirements below) * A **storage bucket** for database backups * **Network connectivity**: port 443 inbound to the cluster's load balancer *** ## Step 1: Provision a Dedicated Kubernetes Cluster Create a Kubernetes cluster dedicated to AgentEye. It should not be shared with other workloads, so the full platform (application services, databases, analytics, and caching) runs in isolation without impacting your existing infrastructure. | Requirement | Details | | ----------------- | -------------------------------------------------------------------------------------------- | | **Distribution** | Any conformant Kubernetes: EKS, GKE, AKS, or self-managed | | **Version** | 1.27 or later | | **Node pool** | Minimum: **3 nodes, 4 vCPU / 8 GB RAM each** (standard general-purpose instances) | | **Storage** | A default StorageClass that provisions block volumes (e.g. `gp3` on AWS, `pd-ssd` on GCP) | | **Load Balancer** | The cluster must be able to provision cloud LoadBalancer services (default on EKS, GKE, AKS) | > Exosphere installs and manages everything else inside the cluster: ingress controllers, TLS certificates, databases, caching, monitoring, and all application deployments. *** ## Step 2: Grant Access to the AgentEye Team Exosphere needs cluster-admin access (or equivalent broad RBAC) to manage namespaces, custom resource definitions, ingress controllers, and storage provisioners. | Requirement | Details | | ----------------- | -------------------------------------------------------------------------------------------------------------------- | | **Access method** | IAM role (preferred for EKS/GKE), kubeconfig, or SSO-based access | | **VPN / bastion** | If the Kubernetes API server is private, provide VPN credentials or bastion access for the Exosphere operations team | *** ## Step 3: Configure Network Connectivity Your network team needs to allow inbound traffic on **port 443** to the cluster's load balancers. The deployment runs two separate load balancers: one for event ingestion (mTLS-protected) and one for the dashboard: | Traffic | Source | Destination | Security | | ------------------- | ------------------------------- | -------------------------------- | ---------------------------------------------------- | | **Event ingestion** | Collector pods in your clusters | Ingest LoadBalancer, port 443 | mTLS (client certificate) + API key | | **Dashboard** | Developer browsers | Dashboard LoadBalancer, port 443 | HTTPS on your domain, passwordless email OTP sign-in | The ingest endpoint is protected by mutual TLS; collectors must present a valid client certificate **and** a valid API key on every request. The dashboard runs on its own load balancer and hostname, with sign-in restricted to your allowlisted email addresses/domains. **DNS records (one-time):** you create two CNAME records under a domain you control — one for the ingest endpoint and one for the dashboard (e.g. `agenteye.your-company.example`) — pointing at the load balancer hostnames Exosphere provides. Exosphere then provisions publicly-trusted TLS certificates for both hostnames automatically, including renewals. > **Port 80 note:** automated certificate issuance and renewal validate over HTTP on port 80 of each load balancer. If your security posture requires restricting the dashboard load balancer to corporate IP ranges, tell Exosphere first — we switch certificate validation to a DNS-based method (one extra DNS record on your side) so renewals keep working behind the restriction. > **Outbound:** Cluster nodes need internet access to pull container images from `ghcr.io`. If your network restricts outbound traffic, allowlist `ghcr.io` or mirror images to your internal registry. *** ## Step 4: Provide a Backup Storage Bucket Database backups are stored in a cloud storage bucket that you own. | Requirement | Details | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Service** | S3 (AWS), GCS (GCP), or Azure Blob Storage | | **Access** | Grant write access to the cluster's nodes via IAM role for service accounts (IRSA on EKS, Workload Identity on GKE) or provide credentials | | **Retention** | You control the bucket's lifecycle policy (retention period, archival rules). Exosphere writes backups; you decide how long to keep them | A single daily backup dumps both PostgreSQL (relational state) and ClickHouse (events and evaluations) into one compressed archive and uploads it to your bucket. Backups also run before every upgrade. *** ## Step 5: Designate a Point of Contact Provide one person or Slack/Teams channel on your side for cluster-level issues: node health, cloud account limits, network changes. Day-to-day operations do not involve this contact. *** ## What We Deploy Once Exosphere has cluster access, the following components are deployed and managed for you: | Component | Role | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **AgentEye Server** | HTTP API that receives events from collectors, runs analytics, and serves data to the dashboard | | **Dashboard** | Web interface for viewing agent sessions, tool calls, model requests, and errors; hosts the optional read-only AI assistant | | **ClickHouse** | Required canonical store for ingested events, analytics, and evaluations | | **PostgreSQL** | Relational store for organizations, API keys, users, dashboards, and saved queries | | **Redis** | Optional shared cache and rate-limit backend; the platform degrades gracefully if it is unavailable | | **AI assistant (optional)** | Internal read-only assistant container; stays disabled until an LLM endpoint is configured | | **Ingress controllers** | Two load balancers (one for mTLS-protected ingest, one for the dashboard) terminating TLS with publicly-trusted, auto-renewed certificates and enforcing mTLS on the ingest endpoint | | **cert-manager** | Automates TLS certificate provisioning and mTLS client-certificate issuance | | **Certificate monitoring** | A scheduled job checks certificate expiry and sends alerts (e.g. to Slack) as certificates approach renewal | The managed offering also operates the platform's evaluation pipeline, which scores agent activity against your evaluation criteria. See [enterprise-docs/assistant.md](/agenteye/assistant) and [enterprise-docs/evaluation-suite.md](/agenteye/evaluation-suite) for what these capabilities deliver. *** ## What We Provide to You After deployment is complete, you receive: | Item | Details | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Dashboard URL** | A hostname under your domain (e.g. `https://agenteye.your-company.example`), served with a publicly-trusted, auto-renewed TLS certificate. You create one CNAME to the load balancer hostname we provide; sign-in is passwordless email OTP | | **Collector endpoint** | The ingest hostname's `/events` path (e.g. `https://ingest.your-company.example/events`), mTLS-protected | | **Client certificate bundle** | Per-cluster: client cert, private key, and CA cert delivered as a Kubernetes Secret manifest. Apply it once per cluster | | **GitHub PAT** | For downloading collector binaries and Python SDK packages | | **Collector API keys** | Scoped keys with `events:add` permission, one per collector deployment | | **Installation guides** | Step-by-step docs for the collector and Python SDK | *** ## What You Do After Setup Your only ongoing work is on your own agent machines, not the AgentEye cluster: 1. **Install the collector** in each Kubernetes cluster running AI agents: mount the client certificate and configure the endpoint URL and API key. See [enterprise-docs/collector-installation.md](/agenteye/collector-installation). 2. **Integrate the Python SDK** into your agent code. See [enterprise-docs/python-sdk.md](/agenteye/python-sdk). 3. **Open the dashboard** in your browser to view agent activity. No cluster operations, no database management, no certificate renewals, no upgrades. *** ## Security * **Data stays in your cloud account.** The cluster, storage, and databases all run in your environment. No data leaves your boundary. * **You control access.** The cluster is in your account. You can audit, monitor, or revoke Exosphere's access at any time. All operations go through your cloud's audit log (CloudTrail, GCP Audit Logs, etc.). * **mTLS on event ingestion.** Every collector request requires both a valid client certificate and an API key. A leaked key is useless without the cert; a stolen cert is useless without a valid key. * **Dashboard access control.** The dashboard runs on its own load balancer, separate from event ingestion, and sign-in is passwordless email OTP restricted to the email addresses/domains you allowlist. An IP source-range allowlist on the load balancer is available on request; because automated certificate renewal must reach the load balancer, Exosphere pairs the restriction with DNS-based certificate validation so renewals keep working. * **Per-cluster certificates.** Each of your clusters receives its own client certificate. If one cluster is compromised, that certificate is revoked independently without affecting others. *** ## Deployment Timeline | Phase | Duration | Your involvement | | -------------------------- | -------- | ------------------------------------------------------------------- | | **Cluster provisioning** | 1-2 days | Provision the cluster and grant Exosphere access | | **Platform setup** | 1 day | None; Exosphere installs all infrastructure components | | **Application deployment** | 1 day | None; Exosphere deploys the server, dashboard, and creates API keys | | **Collector rollout** | 1-3 days | Install collectors in your clusters (with guidance from Exosphere) | | **Production burn-in** | 1 week | None; Exosphere monitors and tunes | Typical total: **\~2 weeks** from kickoff to production-ready. *** ## Support For questions or issues, contact Exosphere at `support@exosphere.host`. *** ## Next Steps * [Getting Started](/agenteye/getting-started): end-to-end walkthrough * [Collector Installation](/agenteye/collector-installation): install and configure the collector * [Python SDK](/agenteye/python-sdk): instrument your agent code * [API Keys](/agenteye/api-keys): manage access and permissions * [Troubleshooting](/agenteye/troubleshooting): common issues and fixes