The fifth step is the big one: by the end, your first client website is live. The site initially runs on a technical Pagoras address so you can try everything straight away. You connect the client's own domain or your own hosting afterwards in the client view; that's deliberately kept out of onboarding.
Two routes
- Connect a GitHub repo: your website already exists as code in a repository. Pagora deploys it straight from there.
- Upload a ZIP: you only have the website files locally. Pagora automatically creates a repository and the hosting from them.
In both cases you also enter the client/project name (required). It creates your first client in the cockpit, which the website belongs to.
Route A: GitHub repo
First you choose where the repo lives:
Private repo (recommended: GitHub app). The usual case. You click "Connect with GitHub" and install the Pagoras app on your GitHub account — just like you know it from other services. During installation you choose under "Only select repositories" which repos Pagora may see. That's all: once the installation is complete, the assistant continues by itself and shows the granted repos for selection. If exactly one repo is granted, it's already pre-selected.
Repo missing from the list? On GitHub under Settings → Installed Apps → Pagoras, extend the grant to include the repo, then click "Refresh" in the assistant. That's also where you can review or revoke the connection at any time — you stay in full control.
The advantage over a token: no long-lived secret is stored with Pagora. The app fetches a short-lived access key (valid for one hour) for every action, and there's no expiry date you need to remember.
Alternative: with a personal access token
If you prefer a token (e.g. because your organisation doesn't allow apps), that still works:
- Create a fine-grained token on GitHub (the button in the assistant takes you straight to the right page; manually: Settings → Developer settings → Personal access tokens → Fine-grained tokens).
- Give it a name (e.g. "Pagoras") and pick a validity, say 1 year. If the repo belongs to an organisation, select it as the "Resource owner".
- Under "Repository access" → "Only select repositories", grant only the client repo.
- Under "Permissions" → "Repository permissions", set only "Contents" to "Read and write". Pagora needs nothing more ("Metadata" is added automatically by GitHub).
- Click "Generate token" and copy the token (starts with
github_pat_…). GitHub shows it only this once.
As soon as you paste the token, the assistant verifies it live and lists the repos it can see. Note: fine-grained tokens expire — the GitHub app connection doesn't.
Public repo (by URL). You simply paste the repo URL (https://github.com/…). The assistant automatically checks whether the repo really is public and tells you if it's private or the URL has a typo. No connection is needed to deploy. Note though: for the AI assistant to make changes later, it needs write access — you can set up the GitHub connection in the cockpit under "Settings" at any point.
Environment variables (if the repo needs them)
Once a repo is selected, Pagora looks inside for a .env template (.env.example and similar names). If it finds one, an input field appears for every key it discovers, with comments from the template shown as hints. The values (API keys and the like) are stored securely with the hosting, not in code and not publicly, and they're already in place for the first deploy.
Fields you leave empty are simply not set. You can add and change them any time in the client view under "Domain & hosting"; see environment variables.
Route B: ZIP upload
You pick a ZIP file with the website files (or drag it onto the field). Pagora unpacks it, creates a repository and the hosting from it, and deploys. From then on this website is versioned like any other.
The deploy: what you see
After "Connect & deploy", the assistant shows progress in three stages: client and website created, hosting created and deploy started, website building and going live. A live ticker shows what's happening right now (checking out the repo, installing dependencies, building, starting the container). A build typically takes two to four minutes.
Three possible outcomes:
- Live: you see a preview of your website right in the assistant and can open it via "View website". (If the preview doesn't load, the site probably forbids embedding; the link works regardless.)
- Taking longer: after a few minutes the assistant moves on even without a finished build; the deploy continues in the background. You'll find the status in the cockpit on the client afterwards. Onboarding deliberately doesn't block you here.
- Error: there's a "Try again" button. If it keeps failing, check whether the repo builds on its own (locally
npm run buildor your project's build command) and whether all required environment variables are set. And otherwise: tom@pagoras.de.