Enterprise adoption guide

An Enterprise lets a company adopt Wilow as a team: shared projects with role-based access, a private marketplace section, per-organization policies, and offboarding that takes effect the instant you remove someone. This guide is the adoption playbook for whoever owns that rollout.

Creating an Enterprise

1. The founding member opens the Enterprises tab in the sidebar and chooses New enterprise.
2. An Enterprise is bound to a GitHub organization your company owns. If you have none yet, the New enterprise form can take you to GitHub's new-organization page (free plan) with the name to use, and creates the enterprise as soon as the organization appears, since GitHub only creates organizations on its own page. Enterprise tools and repositories live in that org — which is what keeps them alive when an individual employee leaves (see offboarding). You must be able to administer that org.
3. The creator becomes Owner. From there you invite members by email and assign roles.

Roles & permissions

Every one of these boundaries is enforced server-side by row-level security and the enterprise edge functions — not merely hidden in the UI. For example, a Reader attempting to publish, or a member trying to promote themselves, is rejected at the data layer.

Member lifecycle & offboarding

• Every member sees every enterprise project. Once someone joins, the enterprise's projects appear in their sidebar under the enterprise's name. Owners, admins and editors open workstreams on them from their own Wilow and post in the project chat; readers follow along read-only. Removing a member closes all of it at once.
• Invite: an Owner/Admin invites an email with a role — use the address the person signs in to Wilow with (the form suggests people you already share projects with). They see a Join card in their Wilow sidebar and also get an email link; either way the invitation is accepted by the account holding that address (or one it has verified in Settings). Until they join, they appear as pending on Members and can't be added to a team yet. Their Wilow accepts the GitHub invitations that come with membership on its own: the enterprise's repositories, and the organisation itself once they are placed in a team.
• Role change: Owners/Admins can change a member's role at any time; the owner role moves only through an explicit ownership transfer.
• Offboarding (the important one): removing a member cuts their read and write access to enterprise projects in the same operation. Their still-valid session immediately matches zero enterprise rows; they can no longer read enterprise chats, write into enterprise threads, or have their engine act on enterprise projects. Project history survives the removal for the remaining members — offboarding cuts access, it does not delete the work.

Policies

Owners and Admins set per-enterprise policies that apply to all members:

• External sharing — allow or forbid sharing enterprise projects outside the enterprise.
• Preview before merge — let each project decide, or require on every enterprise project that a workstream's preview is tried before it merges (the project's own switch is then locked on).
• Standby merging — when the Wilow hosting an enterprise project has been offline for ten minutes, the Wilow of an owner or admin who is online reviews and merges its pull requests in its place; production deploy waits for the host unless the host shared the deploy token through the project's vault. Keep at least two owners or admins if you want this to happen.
• Marketplace installs — open (members may install any public tool) or enterprise-only (members may install only tools your enterprise has published/vetted). This is the primary control for the “local tools run with local privileges” consideration in the Security model.
• Approved providers — constrain which hosting / database / AI providers enterprise projects may use, so work lands only in vetted accounts.

Oversight & privacy

Enterprise projects are creator-private by default — the member who created a project sees it; other members do not, unless added. Owners and Admins have oversight: they can read any enterprise project for governance. This is deliberate and role-scoped — Editors and Readers do not get a window into each other's projects. Oversight applies to enterprise projects only, never to a member's personal projects.

Private-source tools for internal software

Internal tools you never want public can be published private-source: the code is escrowed with Wilow and delivered to installers as short-lived, hash-verified signed URLs — it is never listed publicly or exposed to other users. Combine this with an enterprise-only install policy to run vetted internal tooling across your team without publishing anything to the world. See Publishing → Private source.

Adoption checklist

1. Nominate an Owner and one or more Admins; confirm they can administer your GitHub org.
2. Create the Enterprise bound to that org; invite members with least-privilege roles (Reader by default, Editor for builders).
3. Set the marketplace install policy to enterprise-only if you want to control which local tools members can run.
4. Set approved providers so deployments and databases land only in company accounts.
5. For firewall/proxy allow-listing, use the egress table in the Security model.
6. Document your offboarding step: “remove from the Enterprise” is sufficient to cut Wilow access; also rotate any shared connector credentials the person had on their own machine.
7. Have your security team review the Security model, including its stated limitations.

Common IT questions

• Can Wilow read our chats or code? No — chats are end-to-end encrypted with a key that never leaves your devices, and project code stays in local folders on members' machines. See the data-at-rest table.
• Where does the AI compute run and who pays? On each member's own machine, on the AI backend they/your policy allow — their own OpenRouter key (billed on OpenRouter) or their own Claude subscription (counts against their Claude limits). Enterprise policy can constrain which AI providers are allowed (OpenRouter, Fireworks, Claude).
• Does it open inbound ports? No — outbound HTTPS only.
• How fast is offboarding? Immediate at the data layer when you remove the member.