Create your installation

1. Create the private deployment environment

1. In the private repository, open Settings › Environments.
2. Select New environment, enter the exact name production, and select Configure environment.
3. You may add a required reviewer if your GitHub plan supports it. This is optional; do not change branch restrictions during initial setup.

2. Create a narrowly scoped Cloudflare token

1. Create or sign in to Cloudflare, then select the account that will own this LancerLogin installation. You must be a Super Administrator of that account to create an account-owned token.
2. Open Manage account › Account API tokens › Create Token. If you cannot find this page, use Cloudflare's account API token guide.
3. For Token name, enter a descriptive label such as LancerLogin deployment. This Cloudflare label is only for your reference; it is not the GitHub secret name.
4. Do not choose Read all resources, Write all resources, Edit Cloudflare Workers, or a template under View all templates. None has the exact least-privilege combination LancerLogin needs. Select Start from scratch.

Add four account permissions

Keep the resource selector on the selected account, then enable only these permissions:

Do not add zone or DNS access. LancerLogin uses the default Pages and Workers URLs. It does not need billing, member, user-management, or domain permissions.

5. Choose an expiration appropriate for your organization. If the token expires, replace the GitHub secret before the next update. Leave IP filtering empty unless your GitHub-hosted Actions traffic has a stable approved range.
6. Select Review token and compare the summary with the four lines below. Do not continue if any additional permission appears.
7. Select Create token, copy the token value immediately, and keep the page open until you have stored it in GitHub. Cloudflare displays the value only once.

3. Copy the Cloudflare Account ID

1. From any Cloudflare dashboard page, open Quick search or press Ctrl+K (Command+K on macOS).
2. Enter Copy account ID and select the command with that exact name. This copies the selected account's 32-character ID; it is not a zone ID.

4. Store GitHub environment secrets

Return to the private repository's production environment. Under Environment secrets, select Add environment secret once for each row:

Use secrets, not variables. Do not paste these values into a repository file, issue, workflow input, dashboard form, or chat. The setup code protects first-Admin creation; it is separate from the Admin password you will create later.

5. Run the private installation workflow

1. In the private repository, open Actions › Install or upgrade LancerLogin › Run workflow.
2. For operation, choose create; for release, keep latest stable selected. The workflow resolves the newest public LancerLogin release automatically.
3. For installation_slug, enter a lowercase slug using letters, numbers, and hyphens, such as northside-art-club. It creates exactly <slug>-api, <slug>-data, and <slug>-dashboard.
4. Review those three inputs and select Run workflow. Review and approve the pending production environment deployment if a required reviewer is configured. Use resume with the same slug only after an interrupted setup.
5. The workflow verifies the account-token pair and refuses name collisions before creating anything. When it succeeds, open the Pages dashboard URL from the workflow summary.

123

6. Create the first Admin

Choose local username/password, Google OAuth, or both. Local passwords require at least 12 characters and matching password confirmation; they are stored as salted scrypt hashes. The dashboard and API use one Pages origin through a generated proxy, so strict session cookies are not third-party cookies.

For Google, keep LancerLogin open so you can copy its installation-specific redirect URI. Google calls the configuration area Google Auth Platform; its current sections are Branding, Audience, Clients, Data Access, and Verification Center. Google's Google Auth Platform overview defines the same flow.

Choose the project, branding, and audience

1. Open Google Auth Platform. Select an organization-owned project, or create one and choose Get started.
2. Under Branding, use a recognizable app name such as Your Organization LancerLogin, select a support email, and add a monitored developer contact email. Google's branding guide explains when a logo, homepage, privacy policy, verified domain, or brand verification is required.
3. Under Audience, choose Internal only when the project belongs to a Google Workspace or Cloud Identity organization and every intended dashboard user belongs to that organization. Internal apps do not require Google verification. Choose External when users may have personal Google accounts or belong to more than one organization.
4. For an External audience, Testing is available for a trial and In production publishes the app for ongoing use. LancerLogin requests only basic identity scopes, so Google's documented Testing exception does not require a test-user allowlist and does not impose seven-day authorization expiry. Workspace administrator policy or Advanced Protection can still block access. Review Google's current Audience and publishing-status choices before deciding.

Keep Data Access limited to sign-in

Under Data Access, add or retain only openid, email, and profile. These let LancerLogin validate identity, verified email, and basic profile information. Do not add Drive, Calendar, Gmail, or another API scope for dashboard sign-in. Google's Data Access guide explains scope management, and its OpenID Connect guide documents this exact basic-identity scope set.

Create the Web application client

1. Under Clients, choose Create client, select Web application, and give it a recognizable name. LancerLogin's Worker completes a server-side authorization-code flow; do not create a Desktop app and do not add an Authorized JavaScript origin.
2. Copy the exact value shown by your LancerLogin form into Authorized redirect URIs. Google compares the scheme, host, path, case, and trailing slash exactly.
3. Create the client, then immediately save the client ID and client secret in your organization's password manager. Google displays a newly created secret only once. Paste both into LancerLogin; never put either value in source code, documentation, screenshots, an issue, or chat. Google's Clients guide covers creation and later secret rotation.

Exact Pages callback pattern › https://<slug>-dashboard.pages.dev/api/auth/google/callback

Replace only <slug> with the installation slug. The first-Admin form and Settings → Integrations already show the complete installation-specific value and provide a Copy button.

Finish the appropriate verification

Google's Verification Center and LancerLogin's integration verification are separate. An External app published In production may need Google brand verification before its chosen name or logo appears; sensitive- or restricted-scope review is not required for LancerLogin's basic sign-in scopes unless you add other scopes. After saving credentials in Settings, use Verify with Google and sign in as an active LancerLogin Admin. LancerLogin marks the integration configured only after Google returns a valid identity for that active Admin.

When Google or both methods are selected during first-Admin setup, enter the first Admin's Google email plus the client ID and secret there. This avoids a first-login dependency. The secret is encrypted before storage and is never displayed again. An Admin can later rotate or remove it under Settings → Integrations; Google cannot be disabled or removed unless an active Admin has a usable local password.

7. Create the installation

Community telemetry is disabled. Complete the first-Admin form to continue.

8. Finish Guided Setup

1. Organization - enter the organization name and appearance.
2. Roster - import or add the people who can attend.
3. Kiosk - pair a Raspberry Pi kiosk or the browser simulator.
4. Kiosk input test - test the reader on hardware or send a browser-selected simulated read.
5. Attendance confirmation - confirm a completed test attendance record.

The wizard temporarily replaces dashboard content and focuses on one task at a time. Progress is shared across Administrators. Optional integrations do not block completion. The browser simulator is a software-only check, not evidence of physical kiosk behavior. Confirming the final attendance check opens the completion dialog; select Go to Dashboard. Reopen the checklist later from Settings → Guided Setup without deleting data.

9. Upgrade an existing installation

Open Settings → Updates, select Back up and begin update, and review the pinned release notes. Download the entire-installation backup, save it securely, then confirm the saved file before selecting Start update once. Refresh restores durable progress and does not start another update. Follow the GitHub link when an environment approval is required. Select Reload updated dashboard only after verified completion. Physical kiosk updates remain separate. The completed 1.0.2 migration used the terminal updater through Raspberry Pi Connect remote shell; dashboard-driven kiosk release lookup acceptance remains unproven. Read the complete credential, approval and recovery guide.