The panel's services are configured separately, because they are deployed separately. The two settings that matter most on a first install are where the frontend expects to find the API, and which domains a session should be valid for.
The frontend reads its configuration file before any other asset, and will not initialise without it. Two settings are worth knowing:
api.address — where the API server lives. The frontend has no way to discover this; if it
is wrong, the interface loads and then fails every request.
cookie.domain — the scope on which cookies set by the frontend are valid. Set this to the
parent domain if you want a session to carry across subdomains. If you have built a custom
integration — a billing system on another subdomain, say — and want users to stay signed in
across both, the scope has to cover both names.
These should match the DNS records you created in Installing the panel.
The API's own configuration is separate from the frontend's. Most of it is set up for you by the setup wizard on first run, so there is usually nothing to edit by hand before the first boot.
The panel is configured correctly when you can sign in to the web interface and the interface
can reach the API without errors. If the interface loads but every action fails, api.address
is the first thing to check. If you are signed out as soon as you navigate to another
subdomain, check cookie.domain.
Next: Add your first node.