Self-onboarding

With self-onboarding on, your project’s app can sign a person up, verify their address, and create one customer for them: a tenant copied from your project’s latest published Release, with that person as its administrator. Nobody has to open the Customers page.

Every customer made this way appears on the Customers page with a Signed up mark within a minute. From then on it is a customer like any other: it counts against your quota, receives Releases when you roll them out, and can be suspended, resumed or deleted.

Turning sign-up on

You need to be a project Admin.

The amplify.yml line

Your app’s server reads the key at run time, so the build must write it into .env.production. Starter kits made after self-onboarding shipped already carry this line in amplify.yml, before pnpm build. An older repository needs it added:

    build:
      commands:
        # Self-onboarding: the app's server reads the onboarding key at run time. Server only; never NEXT_PUBLIC_.
        - '[ -z "$BUILDPAD_ONBOARDING_KEY" ] || echo "BUILDPAD_ONBOARDING_KEY=$BUILDPAD_ONBOARDING_KEY" >> .env.production'
        - pnpm build

The key

The panel lists each key by its last four characters, with when it was created, its last use, and how many sign-ups, verifications and customers it made.

• Last use proves the deployment. A key with no last use after you redeployed means the app cannot read it: check the amplify.yml line.
• Rotate issues a second key and writes it to the app in place of the first. The app uses it after its next deployment. Once the new key shows a last use, the panel offers Revoke the old key. A project holds at most two live keys.
• Revoke takes effect on the Engine’s next request. Customers the key already made are kept.
• A key marked Issued outside the Platform was made directly on the Engine by your operator. You can revoke it here.

What a stranger can and cannot do

Anyone who reaches your app’s sign-up page can sign up. They can create a customer only after verifying their address, and only within your limits:

Your app reports the visitor’s network address to the Engine. An app that does not report it puts every visitor in one shared budget of 5 sign-ups per 15 minutes, so a busy app must report it (the Buildpad skills’ sign-up code does).

Copying takes a moment. Customers are copied one at a time on the project’s Engine, about one a second. A burst waits its turn, and the app retries a creation that times out, so nobody gets two customers.

The person who signed up is the new customer’s administrator. Your project’s own administrator account is added to every customer too, as it is for customers you create on the page.

Stopping and turning off

• Stop sign-ups answers every sign-up with “not available” on the app’s next request and keeps the keys. Resume sign-ups turns it back on.
• Turn off revokes every key and removes it from the app. Customers already made are kept.

When a key leaks

If a key reaches someone it should not (a browser, a public repository, a log):

The panel’s From a browser count shows requests that carried a browser’s Origin header: a number above zero means the key reached client code.

Mails

The project’s Admins receive a mail when the project reaches 80 % and 100 % of its customer quota, and when one key creates more customers in a day than your threshold. The mails never carry a key or a person’s address.

For operators

The Engine’s side (its settings, the key’s routes and the limits) is described in the Engine’s operator guide, docs/OPERATOR_CUSTOMER_SELF_ONBOARDING.md in the Buildpad Engine repository.