Grove Pro & Teams

Everything you need for local development is free and open source, forever — serving *.test with HTTPS, bundled PHP/Node/databases, mail, tunnels, the request timeline, and database snapshots. The core is never gated.

Grove Pro unlocks power features on top:

• Database client — browse and edit your databases right inside Grove, auto-connected from each project's .env.
• End-to-end encrypted team secret sync (Teams) — a project's .env, shared securely, never pasted into a chat window.
• Priority support and a commercial license.

Pricing is $99 per seat, per year. Buy as many seats as your team needs and expand any time.

1. Buy — no account needed first

Pick your number of seats at elyracode.com/grove and check out. Your account is created on payment — there's no separate sign-up. The moment your payment clears you receive one email with:

• your license key, and
• your login (email + a temporary password) for the customer portal.

Manage your license, add seats, download invoices, or change payment details any time from the portal (Manage billing & seats uses Stripe's hosted portal).

2. Activate

Paste the key into the desktop app under Settings → License, or from the terminal:

grove license activate GROVE-…

✓ Grove Teams active
  seats  : 4
  email  : you@yourteam.com
  renews : in 364 days

Other commands:

Verification is offline — the key is checked against a public key baked into the app, so Pro features keep working without a connection.

3. Team secret sync

Share a project's .env across your team, encrypted end-to-end. Secrets are encrypted on your machine to your teammates' public keys; the backend only ever stores ciphertext.

Your identity

The first time you use secrets, Grove creates a personal key pair at ~/.grove/identity (the private half never leaves your machine). Share your public key so teammates can grant you access:

grove secret whoami
# age1q9…                ← your public key

Setting and pulling secrets

# Set a secret (encrypted + pushed):
grove secret set myapp DB_PASSWORD=super-secret

# Fetch + decrypt (print, or write a .env):
grove secret pull myapp
grove secret pull myapp --write     # writes ./.env

Inviting teammates

A teammate runs grove secret whoami and sends you their public key. You grant access — Grove re-encrypts the secrets to include them:

grove secret share myapp age1teammatekey…
grove secret members myapp            # who has access
grove secret revoke myapp age1teammatekey…   # remove + re-encrypt

What your client actually trusts

The encryption was never the weak part — it's real age/X25519. The question is who gets to decide the recipient list. If the answer were "whatever the server sends back", then a compromised backend could add its own public key and your next grove secret set would encrypt the whole .env to it, producing ciphertext that looks perfectly valid.

So it doesn't. Your machine keeps its own record, in ~/.grove/secrets/, of the recipients you deliberately agreed to. The server's list seeds that record the first time you see a project and is never again allowed to decide anything. grove secret share / grove secret revoke are what change it.

If the two ever disagree, Grove stops rather than guessing:

$ grove secret set myapp DB_PASSWORD=…
error: the recipient list for "myapp" does not match what you agreed to
       (added: ["age1attacker…"], removed: []). Refusing to encrypt. If this
       change is expected, run `grove secret share`/`revoke` to record it; if
       it is not, your backend may be compromised.

The cost is real and intentional: a legitimate new teammate is refused until somebody runs grove secret share. That is the whole point — widening who can read your secrets should be a decision a person makes, not an announcement a server can make on their behalf.

Payloads are also versioned, and the highest version seen is remembered alongside the pins, so a backend replaying an older .env at you is an error rather than a silent downgrade to a rotated-away password.

A typical team workflow

# You (project owner):
grove secret set myapp APP_KEY=base64:…
grove secret set myapp DB_PASSWORD=…

# New teammate:
grove secret whoami                   # copy your public key, send it to the owner

# You:
grove secret share myapp <their-key>

# Teammate, after cloning the repo:
grove secret pull myapp --write       # .env is ready — app runs

4. Database client

The Database panel in the desktop app connects to each site's database automatically — Grove reads the connection details from the project's .env, so there's nothing to configure.

• Free: browse tables and run SELECT queries in a data grid.
• Pro: edit rows inline (double-click a cell), inspect the schema (columns, indexes, foreign keys), and a production-safety guard that flags prod-looking connections and disables editing there.

Full details in the Database client guide.

5. Security model

• End-to-end encryption. Secrets are encrypted client-side with age (X25519) to the current members' public keys. Only someone holding a member private key can decrypt — the server cannot.
• Zero-knowledge backend. The hosted service stores only ciphertext and public keys. Removing a member re-encrypts without their key, so they lose access on the next change.
• Offline license verification. Licenses are Ed25519-signed by the store and verified against a baked-in public key — no phone-home for daily use.
• Server-side enforcement. The backend independently verifies the license signature, checks it is an active Teams license, and enforces the seat count — so the open-source client can be inspected freely without weakening security.

6. Self-hosting / custom backend

The client talks to https://teams.elyracode.com by default. Point it elsewhere with an environment variable:

export GROVE_TEAMS_SERVER=https://teams.example.com

7. Troubleshooting

FAQ

Does buying Pro change anything about the free version? No. The free, open-source core is exactly the same, forever. Pro is purely additive.

What happens when my license expires? Pro features stop unlocking; the free core keeps working. Renew from the portal to restore them.

Where do my secrets live? Encrypted on the backend (ciphertext only) and, when you pull --write, in your project's .env. Never commit .env to git.

See also: Commands · Architecture.