One question comes up constantly from teams evaluating Grengin: should we launch on Grengin Cloud, or deploy the AWS Marketplace image into our own account?
The good news is that it isn’t a hard fork in features — it’s the same software either way, same schema, same export format. The real decision is about how much infrastructure you want to operate versus how much you’re comfortable handing to Grengin to operate on your behalf. This post walks through both paths, how to deploy each, and a practical framework for choosing.
The two paths at a glance
| Self-host on AWS | Grengin Cloud | |
|---|---|---|
| Where it runs | Your AWS account, your region | Grengin’s AWS account, region you pick at setup |
| Data path | Prompts and documents never leave your tenant | Grengin operates the app, so traffic passes through Grengin’s infrastructure |
| Model provider keys | Stay in your tenant — Grengin never sees them | Stored encrypted in Grengin’s vault (still your keys, still your provider bill) |
| Cost | Free software — you pay your own cloud + model provider bills | Flat fee per workspace + your model provider bills |
| Patching / upgrades | You control when you pull a new image; old versions keep working | Grengin patches continuously; you’re always on the latest release |
| Lock-in | Same image/schema as Cloud — inspect the source yourself | One-click export back into your own AWS account |
| Setup effort | ~5 minutes, no DevOps team required, but you provision the instance | Fastest path — no AWS account or infrastructure needed at all |
No per-seat pricing on either path, and no feature gating — governance, SSO, PII detection, and audit trails ship identically in both.
Deploying on AWS (self-host)
This is the right call if you want the data path to stay entirely inside your own security boundary.
- Get an AWS account with permission to launch an instance — that’s the only prerequisite.
- Launch the one-click Marketplace image from the AWS Marketplace listing (or build from source via the GitHub repo if you want a fully custom build).
- Add your model provider keys (OpenAI, Anthropic, Google Gemini, Mistral, Groq, or Cerebras) — these stay in your tenant.
- Connect SSO (SAML/OIDC against your existing identity provider) and map groups to workspace roles.
- Set budgets and policies by department or project.
- Invite your team. Governance, cost controls, and audit trails are on from day one.
Because it’s the identical Apache 2.0 codebase running either way, you (or your security team) can read the source and verify there’s no hidden behavior before you deploy.
Launching on Grengin Cloud
This is the right call if you don’t want to own an AWS account, an instance, or a patch cycle.
- Sign in at grengin and launch a workspace — no cloud account or DevOps setup required.
- Add your model provider keys. You still bring your own keys and pay providers directly; Grengin just stores them encrypted rather than in your own tenant.
- Connect SSO, set budgets, and configure policies the same way you would self-hosted.
- Invite your team and you’re live — this is generally the faster of the two launches.
Worth noting: some of the Grengin Cloud admin console surfaces (dashboard, LLM management, auth proxy, team member management) are still rolling out, so check the current state of the console when you sign up if those specific screens matter to your rollout.
So which one should you choose?
A few questions tend to settle it:
- Does your compliance posture require that Grengin never touch your traffic? Self-host. On AWS, prompts and documents go straight from your environment to your chosen model provider — Grengin is never in the data path. On Cloud, Grengin operates the app, so traffic does pass through Grengin’s infrastructure (still under your own provider agreements, with keys encrypted at rest, but it’s a different trust boundary).
- Do you have someone who can own an AWS instance and pull updates when they ship? If yes, self-host gives you full control over upgrade timing. If no, Grengin Cloud’s continuous patching means you’re never stuck managing versions.
- Are you optimizing for time-to-first-login? Grengin Cloud is the faster of the two — there’s no AWS account or instance provisioning step at all.
- Do you want to avoid a recurring platform fee? Self-host is free software; you only pay your cloud bill and your model providers. Grengin Cloud adds a flat per-workspace fee on top of provider costs.
- Are you worried about getting locked into whichever path you pick first? You shouldn’t be — Cloud supports one-click export into your own AWS account, and because the schema and image are identical, you can move from Cloud to self-host (or vice versa) without anything breaking.
The practical middle ground
A common pattern in the Grengin community: start on Grengin Cloud to get the team live in minutes and validate the workflow, then export into your own AWS account once you know your governance and compliance requirements are settled. Since both paths run the exact same software with an identical schema, that migration is a data export/import rather than a re-platforming project.
Whichever path you’re on, none of the governance layer — SSO, budgets, PII detection, audit trails — is behind a feature wall. You’re choosing an operating model, not a feature tier.