English · हिन्दी · 简体中文 · 繁體中文 · 日本語 · 한국어 · Türkçe · Русский · Tiếng Việt · ไทย · Deutsch · Español · Français · Українська · Polski · Português (Brasil) · العربية · فارسی · Bahasa Indonesia · Italiano
Built for enterprises to deploy and manage infrastructure — with control that stays yours.
Website · Docs · Status · Buy me a coffee
Quick start · How it works · Your desired state · Repositories · Documentation
curl -fsSL https://raw.githubusercontent.com/gridplatform/grid-core/main/install/install.sh | sudo -E bash
Grid is a self-hosted platform for deploying and running cloud infrastructure. Enterprises use it to keep ownership of how things are rolled out, who can change them, and where access lives — without handing that control to another vendor’s cloud console.
Demo video — coming soon.
- Create remote Terraform state (S3 / GCS / Azure).
- Install Grid on a VM (Compose by default).
export GRID_AUTH_ADMIN_PASSWORD='choose-a-strong-password'
# set GRID_TF_BACKEND / GRID_TF_STATE_BUCKET / … after remote state exists
curl -fsSL https://raw.githubusercontent.com/gridplatform/grid-core/main/install/install.sh | sudo -E bashOr from a clone:
git clone https://github.com/gridplatform/grid-core.git
cd grid-core
cp install/.env.example install/.env # password + GRID_TF_*
docker compose -f install/docker-compose.yml --env-file install/.env up -d --buildOpen http://<host>/. Prefer an instance role / service account on the VM over long-lived cloud keys.
Full path: Install on a VM.
Grid is where your team goes to ask for cloud resources and see what actually changed.
You write down what you want — a network, a server, a database — in config files stored in a GitHub repository you own. Grid reads that description, shows a plan of what would change, and when you approve, creates or removes those resources in your cloud. Every change is saved as a release with live logs, so people can follow along and look back later.
You run Grid on hardware you control. Cloud access stays with that machine’s identity — your config files do not need passwords or keys inside them. If the machine is replaced later, the record of what Grid manages still lives in remote storage you set up once.
In short: say what you want, review the plan, apply with a trail you can trust.
grid-config is an example only. Use it to see how configs look. Do not fork it for your real environment.
For your own setup:
- Create a new GitHub repository under your org or account.
- Put your own config files there (what you want in each environment).
- Point Grid at that repository — not at
grid-config.
Copy ideas from the example; keep ownership of the repository and the settings.
| Repository | What it’s for |
|---|---|
| grid-core | Runs Grid on your machine — the engine behind the scenes, plus how you install it |
| grid-ui | The website you use in the browser |
| grid-cli | The same work from a terminal, without opening the website |
| grid-terraform | Ready-made pieces for common cloud resources (networks, servers, and more) |
| grid-config | Sample configs to learn from — not your real setup (create your own repository) |
| grid-docs | Guides written in plain language |
Done / in progress / planned: STATUS.md.
| Guide | Link |
|---|---|
| Org adoption | organizations.md |
| Remote state | remote-state.md |
| Install (VM / Compose) | install/ |
| CLI (AWS / GCP) | aws-gcp.md |
| Concepts | concepts/overview.md |
Grid stays free and self-hosted. If it is useful to you and you want to help keep it going, buy me a coffee. A small one is plenty. Thank you for being here.
Fork a product repository (core, ui, cli, terraform, docs) → branch → PR against main.
Do not treat grid-config as your private desired-state home.
Issues: grid-core.
MIT © 2026 Grid Platform.
Product repositories (grid-core, grid-ui, grid-cli, and the rest) carry their own LICENSE files under the same terms.
