ivd/sky-lattice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
sky-lattice/docs/customer-landing
History
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
..
CHECKLIST.md Initial Sky Lattice scaffold: blueprint, platformctl, and docs. 2026-07-15 01:48:36 -04:00
README.md Initial Sky Lattice scaffold: blueprint, platformctl, and docs. 2026-07-15 01:48:36 -04:00

README.md

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 customer’s secret store / CI secrets. Never commit keys.

  3. Create the customer project
    On your operator machine:

    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