Free trial · 14 days · Cancel anytime

Organizations

The tenant unit: members, roles, code provider, image registry and subscription.

What is an organization?

An organization is your workspace: it owns the projects, sites, domains, servers and the subscription. Everything you see in the console belongs to the active organization, which you switch from the selector at the top of the sidebar. One account can belong to several organizations, and create new ones from that same selector. The page header shows the organization avatar, its name and a badge with your role.

The tabs on the page

The Organization page is split into five tabs, all visible whatever your role: an action your role does not allow stays on screen, greyed out, with the reason in a tooltip, never hidden. Only the Images tab depends on a permission, and it shows for the roles that can read the registry (Owner, Maintainer, Developer). The open tab is kept in the page address, so you can share a direct link.

  • Members, the list of members and invitations. Visible to everyone.
  • Code provider, the connection that gives Pierrr access to your repositories.
  • Images, where Pierrr pushes the images it builds.
  • Permissions, the read-only matrix of what each role can do.
  • Settings, the profile picture, the organization name and the sensitive actions.

Members and roles

The Members tab lists members and their role. Access control decides what each one can do:

  • Owner, full control: billing, members, code provider connection, image registry, server enrollment and deletion of the organization.
  • Maintainer, creates and manages projects, containers and domains, opens the databases and restarts servers. No billing, no member management, no enrolling new servers.
  • Developer, operates existing containers, without creating or changing a project, without creating, changing or binding a domain, and without database access.
  • Billing, access to billing only (plans, invoices, affiliate program), with no view of the infrastructure.
The member list with their role; pending invitations appear there too.

Actions locked by role

Every action is shown to every member. When your role does not allow it, the button or field is greyed out and a tooltip gives the reason, for example "Your role does not allow changing the organization settings: ask an owner of the organization". This applies to members, the code provider, images and settings: you always see what exists, and whom to ask.

Seen by a Developer: buttons are greyed out and the tooltip explains why.

Inviting a member

Invite a teammate by email and assign a role. Until they accept, the invitation stays in the pending list, where you can resend or revoke it. An owner can remove a member or change their role at any time. Without the right to manage members, the invitation form, the role picker and the trash button stay visible but disabled.

When someone invites you, an "Invitations received" block appears at the top of the Organization page, showing the inviting organization, the proposed role and the expiry date. One click on Accept is enough, no need to find the original email.

The received invitations block, above the tabs.

Code provider connection

From the Code provider tab, link the account of your code provider, the one that hosts your repositories. This lets Pierrr read your code, list branches and trigger builds. Once connected, your repositories can be picked when creating containers. Fine-grained repository selection happens on the code provider side, and the Refresh button resyncs the list after a change. Connecting or disconnecting a provider is reserved to the owner: other roles see the button, greyed out.

GitLab works with gitlab.com and with a GitLab instance you host yourself: in that case, give its address and the application identifiers you create there. Your GitLab projects then show up in the repository picker next to your GitHub repositories, with branch selection and the same folder browsing. Repository, commit and branch links lead to the right host, your own instance included.

An organization can connect several accounts of the same provider, for example two GitHub organizations, and GitHub and GitLab side by side. Each account gets its own card in the Code provider tab, with its repositories, its own Refresh button and its own Disconnect button: disconnecting one leaves the others in place. The repository picker of a new container groups repositories by account, so two accounts owning a repository with the same name stay easy to tell apart. Use the Add an account button next to the list to connect another one.

If another of your organizations is already connected to GitHub, the "Share from another org" button reuses that installation without reinstalling the app. Disconnecting GitHub here leaves the connection active for the organizations sharing it.

If the connection is removed or suspended on the code provider side, the tab says so and offers to restore it: without it, no deployment from your repositories is possible.

The connection that lets Pierrr read your repositories.

Image registry

The Images tab decides where the images Pierrr builds for your containers land. Two targets:

  • Pierrr (hosted), images are pushed into Pierrr's own space. This is the default, included from the Free plan.
  • Your own registry, Pierrr builds the image then pushes it to the registry you name: its address, the namespace (account, organization or folder), the login if needed, and a token with read and write rights on images. Any compatible registry works, as long as it is publicly reachable. Paid plans only.

On the Free plan the Pierrr option is enforced. The token you provide is stored encrypted, with a key specific to your organization, and never shown again: leave the field empty to keep it, paste a new one to replace it. Changing registry needs a new token.

For a project running on one of your servers, the project's Deployments tab lets you choose where its images live: kept on your server and never published (the default), or published to your organization's registry. In the second case, the token travels to your server encrypted for a key only that server holds. The images of a project on your server never go through Pierrr's registry.

The two registry targets: Pierrr (hosted) or your own registry.

Permission matrix

The Permissions tab shows, capability by capability, what each role can do. It is a read-only reference: it cannot be edited, it is there to help you pick the right role before sending an invitation.

The read-only matrix: each role, capability by capability.

Profile picture

The Settings tab holds a “Profile picture” card, above the name field. The owner picks an image there in PNG, JPEG, WebP or GIF, up to 5 MB. There is no cropping to do: Pierrr automatically takes a centred square, resizes it to 256 pixels a side and re-encodes it to WebP. A photo of several megabytes comes down to a few kilobytes, and EXIF metadata, including the location of a picture taken on a phone, is stripped during encoding.

Changing the picture replaces the previous one, which is deleted from storage right away: no orphan image is left behind. The “Remove” button deletes the picture the same way.

Without a picture, the organization shows its initials, up to two characters, on a coloured badge. The colour is derived from the name: it stays the same from one visit to the next and differs from one organization to another, which is often enough to tell them apart at a glance.

The picture is reused everywhere the organization is cited: the organization switcher at the top of the sidebar, including when it is collapsed, the Organization page header, the list of invitations you received, where it shows which organization is inviting you, and the platform admin screens.

Renaming the organization

The organization name is changed from the General card of the Settings tab. Careful, it is not just a label: the organization identifier is derived from it, and it names your containers and your Pierrr subdomains.

A confirmation window shows the identifier changing from the old value to the new one and recalls the consequences before applying: containers are recreated, which briefly interrupts your applications, and Pierrr subdomains built on the old identifier stop working. Your custom domains and your data are not affected.

Renaming, changing the photo, suspending or requesting deletion are visible to every role, but locked for those who do not manage the organization settings.

The profile photo, the General card and the danger zone.

Suspending and reactivating

Still in Settings, the danger zone can pause an organization: access is cut until you reactivate it, which you can do whenever you want. Nothing is deleted in the meantime.

Your primary organization is the exception: it can be neither suspended nor deleted.

Deleting the organization

An Owner can request the deletion of the organization, with an optional reason. The request goes to the Pierrr team, who validate it: in the meantime the organization is suspended and a banner recalls the state, with the date of the request. Deletion destroys projects, domains and associated data, irreversibly.