aethercert
Documentation

MSP customer workspaces

Run aethercert as a managed service: isolated customer workspaces, staff scoped to individual customers, managing another provider, shared customers, slots and licence ownership.

The MSP plan turns aethercert into something you operate for other people. Each of your customers gets a fully isolated workspace; you manage all of them from one login and one invoice, and you decide independently what to charge each of them.

This page covers how it works in the product. The commercial side is on the pricing page and the MSP solutions page.

What isolation means here

Every customer is a separate organization, with its own domains, agents, certificates, authorities, members and event log. It is not a shared tenant filtered by a customer ID.

The practical consequence: there is nothing for one customer to see about another, because there is no query that spans them. Managing ten customers means ten isolated organizations, and you switch between them from the sidebar.

Your own MSP organization is separate again. It has its own certificates and agents if you want them, and it is where slots, billing and the customer list live.

Access to a customer workspace comes from exactly two places, and nothing else:

You manage itYou created the workspace, or its owner accepted your management invitation.
It was shared with youAnother organization that manages it gave you access to that one workspace, at a role they chose.

Neither is inherited any further. Managing an organization does not reach the organizations it manages - see Managing another provider.

Slots and licences

A slot is a licence you own. It has a tier, its own annual subscription and its own renewal date, and it sits in your pool until you assign it to a customer.

Included5 Standard-tier slots with the MSP plan.
Buying moreFrom the customers page, on demand from the dashboard at a discounted MSP rate.
AssigningAssign a slot to a customer and that workspace immediately runs at that tier.
ReassigningUnassign it from one customer and give it to another. The slot keeps its own renewal date.
Auto-renewControlled per slot. Turn it off and the slot lapses at its renewal date rather than billing again.

The tier decides the plan limits inside that customer's workspace - certificate and agent counts, check-in cadence, event log retention - exactly as if they had bought that plan directly.

Customers who pay for themselves

A workspace's plan comes either from your slot pool or from the customer's own subscription - never from both, and the customer list says which.

A customer who bought Standard or Pro directly keeps that subscription when you take over managing them. Their tier, their renewal date and their invoice stay theirs, and the licence column shows the plan as billed to them rather than a slot you can reassign. Assigning one of your slots on top is refused rather than silently applied: it would leave them paying Stripe for a plan they no longer have.

To move such a workspace onto your slot pool, the customer cancels their own subscription first. Once it lapses the workspace drops to Free, and a slot can back it from then on. It also works the other way round: if a managed customer later buys their own subscription, that takes over and the slot you had assigned is released back into your pool rather than billing on for a workspace it no longer licenses.

Who on your team sees which customer

By default every member of your MSP organization works in every customer workspace, at whatever role they hold with you. That is rarely what a larger team wants.

Under Settings > Organization > Members, each person can instead be set to selected customers and assigned the workspaces they actually look after - with a role chosen per workspace. One engineer can be admin in one customer and viewer in another, regardless of their role in your own organization. No customers keeps someone in your own workspace only.

The details, including why owners are always unrestricted, are on Users, roles and access.

Managing another provider

An MSP organization can be managed by another MSP organization - a parent company overseeing several providers, or one provider subcontracting another.

What the managing side sees is deliberately limited:

  • The managed provider's own workspace: its certificates, agents, domains, team.
  • Not that provider's customers. Managing an organization does not reach the organizations it manages in turn.

To open up an individual customer, the provider that manages it ticks it under MSP > Shared Customers and chooses the role that share grants - viewer, member or admin. Everything unticked stays invisible. Unticking it again takes the access away immediately, along with any staff assignments that pointed at it.

Bringing an existing organization under management

Onboarding creates a workspace for a customer who does not have one. For a customer who already uses aethercert, use a management invitation instead: MSP > Customers > Invite an existing organization produces a single-use link, optionally tied to one email address.

An owner of that organization opens the link, picks which of their organizations to hand over, and confirms. Only then does the relationship exist - neither side can create it alone, which is what stops an organization being pulled into a customer list it never agreed to, or attaching itself to a provider that never invited it.

They also choose how much the arrangement covers:

What you get
Operate itEverything operational, deploy targets included. Billing, their member list and deleting the organization stay with them. The default.
Full controlEverything, the same as a workspace you created yourself.

Their existing licence is untouched by accepting, as described above.

Either side can end it, from Settings > Organization > Danger zone on the workspace in question - you from the customer's page under MSP > Customers, they from their own settings. Nobody needs the other's agreement to leave.

Onboarding a customer

From MSP > Customers, create the customer workspace. You provide:

SectionWhat goes in it
Customer detailsName - which appears on invoices and becomes the Stripe company name - a contact person, an email address, and the language for their notifications.
Billing and invoicingWhere invoices are sent (defaults to your own organization's address), phone, country, address, and a tax or VAT number.
LicenceThe workspace tier, taken from an unassigned slot.

The workspace is created immediately and you can start working in it - add domains, enroll agents, issue certificates - before the customer ever signs in, or without them ever signing in at all.

Giving the customer access

Two models, and both are supported:

  • You operate it entirely. The customer never gets a login. You manage their certificates from your own account by switching workspaces.
  • The customer sees their own workspace. Invite them into their organization at whichever role fits - viewer for read-only visibility, member for day-to-day work, admin if they should configure deploy targets themselves.

Roles work the same inside a customer workspace as anywhere else, so "read-only visibility for the customer, full control for us" is just a viewer invitation.

Billing and support responsibility

Who is responsible
Paying aethercertYou. One invoice covers your plan and every slot. A customer who kept their own subscription is invoiced by aethercert directly for that one workspace.
Charging the customerYou, at whatever price you set. aethercert has no relationship with your customer.
First-line support for the customerYou. That is what the customer is paying you for.
Support for youaethercert. As an MSP you are a direct customer, with a direct line.

A customer workspace's own in-app support screen points its users at you, not at aethercert, using the contact details on your MSP organization. Keep those current - they are what your customers see.

Ending a customer relationship

Unassign the slot. The workspace keeps one of the included Standard places if you still have one free, and otherwise drops to Free-plan limits - it is never deleted, so nothing is destroyed and nothing is retracted: certificates already deployed keep working, and the data is still there if the customer comes back.

Then either reassign the slot to a different customer, or turn its auto-renew off and let it lapse at its renewal date.

Detaching the workspace ends the relationship itself. The workspace becomes independent, its licence goes back to it (a slot you were paying for is released into your pool), and everything that hung off the relationship disappears with it - shares of that workspace, and your team's assignments to it.

Deleting a customer workspace outright is a separate, deliberate action. Note that an account deletion is blocked if it would strand an MSP customer workspace, so a workspace cannot disappear as a side effect of someone closing their personal account.

On this page