Self-Hosted Deployment
Sundial can be deployed entirely within your own cloud account as a single-tenant, self-hosted platform. This page describes the deployment model — what infrastructure is created, how Sundial connects to your data warehouse, and where data lives.
All compute, storage, and credentials remain in infrastructure you own and administer. Sundial does not maintain a persistent connection back to its own systems, and your data never leaves your environment.
Supported clouds and warehouses
The self-hosted reference deployment targets:
- AWS with Snowflake — described in detail below.
- GCP with BigQuery — analogous components (GKE in place of EKS, Cloud SQL, Memorystore, GCS, Secret Manager, Artifact Registry).
The provisioner, infrastructure model, and data-residency guarantees are identical across providers — only the specific managed-service names differ.
1. Infrastructure
Sundial is deployed into your cloud account as a self-contained platform. The provisioner creates all required infrastructure and deploys application services onto Kubernetes. You retain full administrative access to every component.
Components
| Component | Service (AWS) | Service (GCP) | Purpose |
|---|---|---|---|
| Compute | Amazon EKS (2 clusters) | GKE (2 clusters) | Platform cluster + isolated kernel cluster for sandboxed Python execution (Kata Containers). |
| Database | Amazon RDS PostgreSQL | Cloud SQL for PostgreSQL | Platform configuration, application state, and authorization data. |
| Cache | Amazon ElastiCache Redis | Memorystore Redis | Session state, query caching, real-time messaging. |
| Object Storage | Amazon S3 | Google Cloud Storage | User uploads, connector staging, Pulumi state, snapshots, query results. |
| Search & Indexing | OpenSearch (self-hosted on EKS via Helm) | OpenSearch (self-hosted) | Insights store, log indexing, audit trail. |
| Networking | Amazon VPC (2 VPCs) | VPC (2 networks) | Network isolation between platform services and the kernel execution environment. |
| Secrets | AWS Secrets Manager | Secret Manager | Encrypted credential storage for database, warehouse, LLM, and integration credentials. |
| Container Registry | Amazon ECR | Artifact Registry | Sundial container images, pre-loaded during setup. |
Architecture overview
Deployment process
Sundial is deployed using a Pulumi-based CLI provisioner that automates the creation of all infrastructure components. The provisioner applies infrastructure as a sequence of Pulumi stacks in dependency order — Pulumi state itself is stored in an object-storage bucket inside your account.
What you provide
- Cloud account with administrative access
- IAM roles or service accounts for managed Kubernetes
- VPC and networking configuration
- DNS and TLS certificates
- Completed configuration template
What Sundial provides
- Container images (loaded into your registry)
- Provisioner CLI binary
- Configuration template with secret slots
- Deployment runbook and support
The provisioner applies stacks in phases — foundational infrastructure first (networking, Kubernetes, databases, caches, storage, secrets, registry), then in-cluster identity, then platform application services, and finally the API ingress.
Configuration and secrets are maintained in two separate files. The configuration file contains structural settings and can be safely shared. The secrets file contains actual credentials and is never committed to version control.
2. Warehouse access
Sundial connects to your data warehouse to discover schemas, run analyst queries, and write materialized tables. All connections use TLS with certificate verification, and credentials are stored in your managed-secrets service.
The reference example below covers Snowflake. The same model applies to BigQuery and other supported warehouses — only the credential format and grant statements differ.
Authentication methods (Snowflake)
| Method | Credentials | Recommendation |
|---|---|---|
| Key-Pair Authentication | Username + RSA private key (2048-bit min.) | Recommended |
Snowflake has deprecated Username + Password based authentication without MFA. Reference: https://docs.snowflake.com/en/user-guide/security-mfa-rollout?utm_source=chatgpt.com
Required connection parameters
| Parameter | Description | Example |
|---|---|---|
account | Snowflake account identifier | xy12345.us-east-1 |
warehouse | Compute warehouse for query execution | SUNDIAL_WH |
role | Snowflake role used for all operations | SUNDIAL_ROLE |
database | Target database | ANALYTICS_DB |
schema | Target schema | PUBLIC |
To configure multiple databases or schemas, supply each as a comma-separated list — e.g., database: ANALYTICS_DB,MARKETING_DB and schema: PUBLIC,REPORTING.
Integration approach
Sundial connects to your warehouse using the official driver/connector and issues SQL statements directly. Sundial can optionally use dbt Core and the Data Modeling Agent to generate data lineage when enabled.
3. Read-only vs read/write access
Sundial uses two scopes of warehouse access. Read-only covers schema discovery, lineage extraction, and analyst queries. Read/write is required to make full use of Sundial's data modeling and AI features — Sundial materializes tables such as pre-aggregates in your warehouse that power dashboards, metrics, and the AI-driven analytics suite. The two scopes are described separately below so you can review the grants for each.
Read-only mode — baseline
Read-only access is sufficient for schema discovery, lineage extraction, and all analyst queries Sundial issues against your warehouse. Granted on its own, it enables discovery and analytics but not the materialization required by the data modeling and AI features described in the next subsection.
Operations performed (Snowflake example)
| Operation | SQL Pattern | Purpose |
|---|---|---|
| Schema discovery | SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES | List available tables in a schema |
| Column introspection | DESCRIBE TABLE {table} | Discover column names, types, and nullability |
| Lineage extraction | SNOWFLAKE.ACCOUNT_USAGE.OBJECT_DEPENDENCIES | Map table-to-table dependencies (Enterprise+ optional) |
| Access history | SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY | Column-level lineage (Enterprise+ optional) |
| Analyst queries | SELECT ... FROM {tables} | Sundial query execution (always read-only) |
The ACCOUNT_USAGE views are queried only if the role has the IMPORTED PRIVILEGES grant on the SNOWFLAKE database. If those grants are not present, Sundial degrades gracefully — lineage features are disabled but all other read-only operations continue to work.
Required Snowflake grants
GRANT USAGE ON DATABASE my_db TO ROLE my_role;
GRANT USAGE ON ALL SCHEMAS IN DATABASE my_db TO ROLE my_role;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE my_db TO ROLE my_role;
GRANT SELECT ON ALL TABLES IN SCHEMA my_db.my_schema TO ROLE my_role;
GRANT SELECT ON FUTURE TABLES IN SCHEMA my_db.my_schema TO ROLE my_role;
GRANT SELECT ON ALL VIEWS IN SCHEMA my_db.my_schema TO ROLE my_role;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA my_db.my_schema TO ROLE my_role;
-- Optional: enables lineage features on Enterprise+ accounts
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE <sundial_role>;
Read/write mode — required for AI & data modeling
Read/write access is required to make full use of Sundial. The data modeling layer and AI suite depend on materializing pre-aggregated tables back into your warehouse — these tables are what dashboards, metric definitions, and AI-driven analytics query against. Without write access, you get schema discovery and analyst queries but not the pre-aggregation pipeline that powers the rest of the product.
The write grants are scoped to the schema you designate for Sundial-managed tables; they do not extend to schemas your own procedures and tasks write into.
Additional Snowflake grants for write mode
GRANT CREATE TABLE, CREATE VIEW ON SCHEMA my_db.my_schema TO ROLE my_role;
-- write on existing and future tables in just this schema
GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA my_db.my_schema TO ROLE my_role;
GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON FUTURE TABLES IN SCHEMA my_db.my_schema TO ROLE my_role;
GRANT CREATE TABLE, CREATE VIEW ON SCHEMA <db>.<target_schema> TO ROLE <sundial_role>;
GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, ALTER ON ALL TABLES IN SCHEMA <db>.<target_schema> TO ROLE <sundial_role>;
GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, ALTER ON FUTURE TABLES IN SCHEMA <db>.<target_schema> TO ROLE <sundial_role>;
4. Data residency
Sundial's self-hosted deployment is designed so that your data stays within infrastructure you control. The following diagram and tables show exactly what stays in your environment and what — if anything — crosses the boundary.
Data flow boundary
Never touches Sundial: no persistent back-channel, no telemetry to Sundial, no data exfiltration path. Container images are pre-loaded into your registry during setup and updated via the same process on upgrades.
Summary table
| Data Category | Location | Crosses Boundary? |
|---|---|---|
| Raw data (warehouse tables) | Your warehouse account | No |
| Computed metrics & query results | Your warehouse, object storage & database | No |
| Platform state (config, users, permissions) | Your managed PostgreSQL | No |
| Cached data & sessions | Your managed Redis | No |
| Credentials & API keys | Your managed-secrets service | No |
| Application logs & audit trail | Your OpenSearch | No |
| Identity & authorization data | In-cluster, on your Kubernetes & database | No |
| Container images | Your container registry | No (pre-loaded during setup) |
| LLM API calls (AI features) | Customer-configured provider | Optional — your API keys, your provider |
Once deployed, the platform does not phone home, send telemetry, or maintain any persistent connection to Sundial infrastructure. Container images are pre-loaded into your registry during initial setup and updated via the same process during upgrades.
LLM API calls (AI features)
When Sundial's AI features are in use (e.g., natural-language queries, AI-driven analytics), the platform sends prompts to your configured LLM provider using your API keys. Supported providers include OpenAI, Anthropic, Google Gemini, Groq, and Vertex AI. These calls originate from your Kubernetes pods and go directly to the provider — they do not route through Sundial systems.
If AI features are not in use, no external LLM calls are made.