"Organisations, servers and sites: how they fit together"

SrvYard has only a few ideas, and they nest. An organisation holds your people, your billing and your connections to other services. Servers are the machines your organisation runs. Sites are the applications on those machines. Once you can picture that tree, the sidebar, the permissions and the plan limits all make sense.

This article explains each level, what lives at it, who can see it and what limits apply. It is a reading page: there is nothing to configure, but you will want to know it before you invite colleagues or connect your first provider.

Before you begin#

• An account. See Create your account, verify your email and set up two-factor.
• No servers needed. The screenshots use the demo organisation, Acme Studio, but the model is the same for an empty one.

1. The big picture#

Account (you)
 └── Organisation (Acme Studio)
      ├── Members, roles and teams
      ├── Connections: server providers, source control, storage, notifications
      ├── Servers (acme-web-01, acme-db-01, ...)
      │    └── Sites (acme-shop.example, api.acme-shop.example, ...)
      └── Plan, billing and usage

Three rules follow from the tree:

• A site belongs to exactly one server. To move it, create it on another server (see Delete, rename or move a site).
• A server belongs to exactly one organisation, though you can transfer it to another organisation you own (Rename, resize, delete or forget a server).
• People belong to organisations through roles. Your account can be a member of many organisations with a different role in each.

2. Organisations#

Open Organizations in the sidebar to list every organisation you belong to.

1. Add organization. Creates another one. Your plan decides how many you can have: Hobby allows 1, Pro 3, Business 10.
2. Your role. Owner in both rows here. The role decides what you can do inside that organisation.
3. Settings. Opens the organisation's settings.

Every account also gets a personal organisation at sign-up, such as alex-rivera. It is an ordinary organisation, handy for your own experiments.

An organisation is the boundary for almost everything: servers, sites, databases, backups, recipes, API tokens and the activity log are all per organisation. Nothing leaks between organisations unless you transfer it on purpose. The switcher at the top of the sidebar changes which one you are looking at, and every address starts with its handle, for example /acme-studio/servers.

3. What an organisation holds#

1. Organization name and handle. The handle appears in addresses and is shown under the name with a Change link.
2. Require two-factor authentication. When on, members without two-factor can only open their security settings until they turn it on. A cheap, strong protection for a team.
3. Tags. Coloured labels (here production, staging, legacy and client work) with how many servers and sites use each. You attach them from a server's or site's settings and filter lists by them.

The same Organization settings area has the rest: Members, Roles, Teams, Security (SSH keys), Source control, Server providers, Storage providers, Billing, Integrations, Notifications, Webhooks and Export / import. These are the connections that servers and sites use.

4. Members, roles and teams#

1. Invite member. Sends an email invitation with a role. See Invite team members.
2. Pending invites. Invitations not yet accepted, each with its role and expiry date, and Revoke to withdraw it.
3. A member. Name, email, Role, sign-in method, status and when they joined. Roles here are Owner, Admin, Manager, Developer and Viewer; you can also define custom roles. See Roles and permissions.

A role says what a person can do. A team says which servers and sites they can see.

1. New team. Creates a group.
2. A team. Shows how many members, servers and sites it covers. Owners and admins always see everything; other members see what their teams share, plus what they created themselves. See Limit members to certain servers and sites.

5. Servers#

A server is one machine, either one SrvYard created at a cloud provider or one you already had (Connect an existing server). Each server has a type that decides what is installed (app, web, worker, database, cache, load balancer or Meilisearch), a status, an address and a set of tabs for everything on the machine: sites, scheduled jobs, daemons, databases, services, firewall, SSH keys, monitoring and backups. Read the page in Read the server overview.

Servers are the unit of your plan's server limit: Hobby includes 1, Pro 10 and Business has no limit. Archived servers do not count.

6. Sites#

1. New site. Creates a site of the type you choose (Create a site on your server).
2. A site. Its name, type, tags, PHP version, repository and branch, status and when it was last deployed.
3. The server column. The one machine the site runs on.

A site owns its domains, certificate, environment variables, deployments, logs, background processes and, optionally, a database. Sites are counted against your plan's site limit (Hobby 3, Pro and Business unlimited) and its monthly deployment allowance, as shown on Usage.

7. A worked example#

Imagine a small agency. It creates one organisation, connects one cloud provider and one GitHub account, and invites four colleagues: one Admin, one Manager, one Developer and one Viewer. It creates two teams, one for the shop project and one for the platform. The platform team is given every server; the shop team is given the web server and the sites of the shop only. The developer on the shop team can deploy those sites but cannot see the database server, and the viewer can look at everything the shop team shares but change nothing. The provider and GitHub connections are made once, by someone with permission to manage them, and every member of the organisation benefits from them without ever seeing the tokens. The plan, the invoices and the usage page belong to the organisation, not to any one person.

Keeping that picture in mind answers most "where do I find it?" questions: people, billing and connections are organisation settings; machines are servers; applications are sites; and access is a matter of roles and teams.

8. What is per organisation, and what is per account#

Some things follow you: your profile, your password and two-factor settings, your personal API tokens and your notification preferences live under your account settings and are the same in every organisation. Everything else follows the organisation: members and roles, connected providers, source control and storage connections, servers, sites, recipes, dashboards, billing and the activity log. A practical consequence is that connecting GitHub in one organisation does not connect it in another, and that a colleague who leaves is removed from one organisation without affecting your account or theirs.

Troubleshooting#

• I cannot see a server my colleague mentioned. You are not on a team that shares it, or your role does not include servers. Ask an owner or admin.
• The server limit reached message appears. Archive or delete a server you no longer need, or upgrade the plan (Plans and limits compared).
• Sites are in the wrong organisation. Servers can be transferred; sites move with their server. There is no transfer for a single site.
• A member cannot use a connection. Providers, source control and storage connections are per organisation and need the matching permission.
• Which organisation am I in? Look at the switcher at the top of the sidebar and at the first part of the address.

Related#

• A tour of the dashboard, sidebar and command search: the interface around this model.
• Invite team members: add people with the right role.
• Create, rename and switch organisations: manage more than one.
• Connect an existing server: add your first machine.