sky-lattice/docs/customer-landing/README.md
VG 611ad214fe Initial Sky Lattice scaffold: blueprint, platformctl, and docs.
Encode intent/decision/plan workflow for Snowflake platform delivery so engagements share a durable recipe instead of one-off LLM chats.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-15 01:48:36 -04:00

58 lines
2.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# How To Land Sky Lattice in a Customer Environment
This guide is for operators bringing Sky Lattice to a new customer Snowflake account.
## Prerequisites
- Customer Snowflake account (or ability to create one)
- Customer git host (GitHub/GitLab) or agreement that you host the customer project
- Place to store secrets (CI secrets / Vault)
- Optional: Cursor for skill-based UX
## Steps
1. **Bootstrap automation identity (one-time, manual)**
As `ACCOUNTADMIN`, create a Terraform/service user with key-pair auth and roles sufficient for platform objects (typically a dedicated automation role; avoid day-to-day ACCOUNTADMIN after bootstrap).
2. **Store secrets**
Put the private key and account identifiers in the customers secret store / CI secrets. Never commit keys.
3. **Create the customer project**
On your operator machine:
```bash
platformctl init <customer> --mode greenfield # or brownfield
platformctl wizard --path customers/<customer>
platformctl validate --path customers/<customer>
platformctl plan --path customers/<customer>
```
4. **Push to customer git**
Push `customers/<customer>/` to their repository (or your managed repo per contract).
5. **Wire CI**
The template workflow under `.github/workflows/terraform.yml` is a starting point. Add credentials, remote TF state backend, and real `terraform plan/apply` gates.
6. **First apply**
Run through CI or `platformctl apply` once credentials and provider resources are wired.
7. **Hand off**
Point customer admins at recipes: add domain, grant patterns, drift. Approvers only need to read Terraform/plan summaries.
## Expected results
- Customer repo holds intent + decisions + terraform
- CI can plan changes via PRs
- Blueprint remains pinned by version; full blueprint source stays with you unless air-gapped vendoring is required
## Troubleshooting
- **No intent.yaml** — run from the customer project or pass `--path`
- **Policy errors on overrides** — add `platformctl decision add` and link `decision_id`
- **terraform missing** — fine for v0 graph apply; install Terraform when enabling live provider apply
## Related
- [Bring-up checklist](CHECKLIST.md)
- Recipes under `docs/recipes/`