The servers

A project’s infrastructure is named after the stage it serves. Servers are created as the project reaches each stage, so a project early in its life has only the first of them. That is normal rather than a setup step you missed.

The Design Server is the odd one out: there is no machine reserved for you in Design. It is the platform building and serving your preview, shown as a server so the dashboard can tell you at a glance whether your design preview is up. It costs nothing to keep, holds no data, and is never monitored or backed up.

It is also the one server that goes away. Once the project moves on to Build, the real app on the Build Server replaces the mocked preview, and the Design Server is shown as retired on the dashboard: shut down for good rather than waiting to be restarted. The other three stay for the life of the project.

Signing in on the Build Server

Every app comes with sign-in already built in. You don’t have to ask for a login page, and the agent should not build a second one.

On the Build Server you won’t see that sign-in screen. The preview signs you in automatically as yourself, using your Sapilon account’s email, so you go straight into the app. The real screen needs sign-in settings that only a deployed environment has, so a signed-in preview is expected, not a sign that login is missing or broken. On the Design Server there is no sign-in at all, since the screens run on mocked data.

The real sign-in screen, and signing out and back in, first appear on the Rehearsal Server. Check that journey there.

In the meantime you can still ask the agent for sign-in work. It changes what happens around sign-in, such as which pages need an account or what a new user sees first. It does not rebuild the screen.

Publishing to the Rehearsal and Live Servers

The Rehearsal and Live Servers are both handled on the Publish page, under Go Live. When your project reaches Live, Next Steps opens with it: Publish to Live is the first card on the Live tab.

Publishing is one button. The first time you publish to a server, Sapilon also sets the server up, creating everything it needs in order:

• Web address & security certificate: your domain, secured so browsers show the padlock. You can put your app on your own address once the server exists.
• Database: a private home for your app’s data, with its tables created.
• App backend: the part that saves data and runs your business rules.
• Web app: your app’s screens, published at their address.
• Sign-in: accounts and secure sign-in for your users.

That first time is the slow one: the certificate and the database can take a while. You can leave the page or close the tab. Publishing carries on, and you get a notification when it ends. After that, publishing only puts the new version on the server: database changes, then the app backend, then the web app.

Each publish is kept as a numbered release (Release 1, Release 2, and so on), listed on the same page with the changes it contains and which server runs it. Publishing the same version again reuses its release instead of making a new one. On the Live Server, the button offers the release the Rehearsal Server is running, so what reaches real users is what you already tried.

If a publish fails, the page says which part and why. Publish again picks it back up; the parts already done stay done. A release can also go back on a server from its detail panel, as long as the database hasn’t changed since that release. Once it has, publish a new release that undoes the change instead.

Two more actions are in the page’s menu. Repair server sets every part up again, keeping what already exists, then publishes; use it when a publish can’t reach something setup should have created. Remove server takes the whole server down in one go, database included. Your web address and its certificate are kept, and your release history stays.

The parts of a server, and how each is doing, are under Cloud services on the same page, as a checklist and as your architecture diagram coloured by status. Sometimes a part shows Couldn’t confirm. That means Sapilon could not check it from outside, not that it is missing. It usually happens to a server set up before that check existed.

What is deployed on one

A server runs a release: a numbered version of the project, published to it at a specific time. The Publish page shows which release each server runs; see promoting between stages for how a release moves up the ladder. Two servers can run different releases, and usually do: Rehearsal runs ahead of Live by design.

Health

Rehearsal and Live are monitored, and problems are recorded as incidents against the environment they happened in. An incident stays open until it is resolved, so “healthy” means nothing is currently open rather than nothing has ever gone wrong.

Severity matters: something being down is an outage, an error is a fault that has not taken the app down, and a warning is worth reading but not worth waking up for.

Backups

Backups run on a schedule for the servers that hold real data, and each one either completed or it did not. A backup that failed silently is worse than none. Restores are drilled deliberately in Rehearsal, while nothing depends on them, rather than attempted for the first time during an incident.

What they cost

Your first 50 Build Server hours are free. They are counted per organisation, across all its projects and people, and they are a one-time allowance: they do not reset each month. After that the Build Server costs €1 an hour, drawn from your wallet (including starter credit) when a session ends.

A session is the time from the server starting until it shuts itself down, about ten quiet minutes after you stop working. A session that crosses the 50-hour mark is split: the part before it is free, only the rest is charged. The Costs report lists the Build Server with its hours of running.

Once the free hours are used, a new Build Server starts only while your wallet can pay. If it is empty, top it up to keep building. An organisation can run up to three Build Servers at once.

Rehearsal and Live do draw from the wallet, for as long as they exist, whether or not anyone is using them. They are standing infrastructure serving real users, so they are billed as hosting. That is the argument for tearing down an environment when a project is paused.

The Design Server, not being real infrastructure, costs only the agent work you ask for.

Next: Promoting between stages · Wallet and top-ups