Organizations

An organization is a shared workspace: its projects belong to the team, not to any one account. Everyone you add can deploy, roll back, manage env vars and custom domains, and read logs and analytics on the org's projects — from the console and the CLI alike.

There are no seat fees. Slew's plans are flat; adding your whole team to an org costs nothing extra.

Creating an organization

In the console, open the workspace switcher in the header and choose New organization, or from the CLI:

slew org create acme --display-name "Acme Inc"

Names are 3–40 characters of a-z, 0-9, and -, and are unique across slew. You become the org's owner.

The switcher then scopes everything: with acme selected, the projects list shows the org's projects and new projects are created in the org. From the CLI that's explicit:

slew init my-app --org acme    # create a project in the org
slew projects --org acme       # list the org's projects

An org project works exactly like a personal one — same URLs, same deploys, same slew.json link. Only the ownership differs.

Icon

Orgs get an icon automatically. As soon as an org project deploys from a GitHub repo, the console shows the avatar of the GitHub account those repos belong to; a shared installation does the same even before any repo is linked. Admins can also upload their own under Organization settings → Icon (PNG, JPEG, WebP or GIF, up to 512 KB) — an upload always wins over the GitHub fallbacks, and removing it brings them back.

Roles

Role	Can
member	Everything on the org's projects: create, deploy, roll back, env vars, domains, logs, stats
admin	Member, plus: delete projects, invite and remove members, revoke invites
owner	Admin, plus: change roles, edit the org, delete the org

Two guardrails: an org always keeps at least one owner (the last owner can't leave or be demoted), and deleting an org requires deleting its projects first — so taking a site down is always an explicit act.

Inviting people

Invites go by email, from the org's settings page in the console or:

slew org invite acme dev@example.com --role member

The invitee gets a link to accept; they sign in with GitHub (creating their slew account on the spot if they don't have one) and they're in. Links expire after 14 days and work exactly once. Pending invites can be revoked at any time.

Every invite also returns its accept link once at creation — if the email doesn't arrive, copy the link from the console and share it however you like.

Managing membership

slew org list                  # your orgs and your role in each
slew org members acme          # who's in
slew org invites acme          # pending invites (admin+)
slew org revoke-invite acme <invite-id>
slew org remove acme <github-login>
slew org leave acme

Role changes (promoting an admin, handing over ownership) live in the console's org settings and are owner-only.

Membership can also gate the org's sites: set a project's access to org members and visitors must sign in with GitHub and belong to the org to view it — see access control. Removing a member locks them out of those sites within a minute.

Org tokens: CI and AI credentials that outlive membership

The principle: nothing a team depends on should break when one person leaves. Personal tokens authenticate a person — when someone leaves an org, their token instantly loses access to its projects. For the things that must keep running, orgs own their own credentials:

slew org token acme deploy "github-actions"   # CI credential
slew org token acme ai "production app"       # AI gateway key

Both are org-owned: they keep working regardless of who created them or who has since left, and admins can list and revoke them (slew org tokens, slew org revoke-token, or the console's org settings).

• A deploy token is deliberately narrow: it can list the org's projects, upload deployments, and roll back — nothing else. No domains, no env vars, no org management. Put it in CI as SLEW_TOKEN and it deploys; leaked, it can't do much else.
• An org AI key works like any gateway key and attributes usage to the organization. It draws from the org's own monthly AI credit — a member's personal keys can run dry without ever touching it, and vice versa. Org AI usage shows up in the org's settings so you can see where it came from.

Shared GitHub installations

Git push-to-deploy needs a GitHub App installation, and installations belong to whoever installed them. For an org project that would mean the repo link silently depends on one member — so members can share their installation with the org:

slew org share-github acme <installation-id>

Once shared, any member can link org projects through it and the link survives the sharer leaving slew's side of the equation. The sharing account keeps ownership (GitHub still trusts them); unsharing is theirs or an admin's call. The console labels every installation in the repo picker — yours or shared with <org> — so you always know what a repo link will depend on.

Plans and quotas

An org has its own plan. It starts on Free and can subscribe independently of anyone's personal account: its projects, custom domains, server apps kept ready, bandwidth, and AI credit all count against the org's own allowance — never against a member's, and a member's personal usage never eats the org's. Nothing about the org's plan hinges on any one member: whoever leaves, the subscription stays the org's.

Billing lives with the rest of the org's settings: with the org selected in the workspace switcher, the console's Billing page shows the org's plan, usage, and invoices. Admins can view it; changing the plan, the billing details, or cancelling is owner-only — like deleting the org. The invoice carries the org's own name and VAT number, set in the org's billing details.

Because every org is a fresh free-tier allowance, your plan caps how many orgs you can create (Free: 1, paid plans more). Joining orgs, or taking over ownership of an existing one, is never capped.

Billing stays flat per organization — no per-seat pricing, invite your whole team for nothing.

Current limits

• Projects can't yet be moved between your personal workspace and an org — choose at creation.
• One GitHub installation can be shared with one org at a time.