Appearance
Getting access
Page summary: Get to the environment or system you need.
Use this when: Use this as an internal runbook, not as product-learning material.
- Dev, staging, and production are different environments.
- A configuration value seen in production files is not the same as reproduced production behaviour.
- Some access owners and local setup details are still incomplete.
What exists, where it lives, and what you need to see it.
Draft. The addresses and settings below are read from the service's configuration files. Who to ask for each thing still needs filling in by whoever grants it.
Checked 5 August 2026.
The three environments
| Address | What it is for | |
|---|---|---|
| Dev | ems.beta.deltahq.com | Day-to-day testing. Safe to break. Everything in this handbook marked "confirmed in dev" was checked here. |
| Staging | ems.staging.deltahq.com | Pre-release checking. |
| Production | ems.deltahq.com | Real customers, real money. |
Related addresses follow the same pattern — payment at payment.ems.*, refunds at refund.ems.*, sign-in at sso.*, the partner system at pms.*.
Nothing in this handbook has been checked against production. Settings differ between environments, so a rule confirmed in dev is not automatically true for customers.
Settings that differ between environments
Most behaviour is the same everywhere. These are not.
| Setting | Dev | Staging | Production |
|---|---|---|---|
| Propose-changes moves a booking to "pending customer confirmation" | on | on | on |
| Invoice status updates from task management | off | off | off |
| Removing all coupons when editing a booking | on | on | off |
| New reseller behaviour | on | on | on |
| Task management | on | on | on |
| Notifications | on | on | on |
| Adding items to a booking | on | on | on |
| Editing a booking skips the availability check | on | on | on |
| Editing a booking skips the price check | on | on | on |
Two things worth knowing from that table.
Propose-changes is on everywhere, including production. So the older behaviour described in propose-changes always moves the booking to pending (BST-005) is not reachable anywhere. That question is closed.
Editing a booking skips both the availability and the price check, in every environment. Combined with availability is not actually enforced when a booking is created (AVL-006), that means neither creating nor editing a booking checks whether there is room.
What you need, and who to ask
| To do this | You need | Ask |
|---|---|---|
| Look at the dev dashboard | A dev vendor account | to be filled in |
| Look at a vendor's public booking page | Nothing — it is public | — |
| Read the service code | GitHub access to the ILUMINA-Pte-Ltd organisation | to be filled in |
| Read the shared code library | Access to ems-apis in the same organisation | to be filled in |
| Run the service locally | Go, a database, and the private code libraries over SSH | to be filled in |
| See the hosting and logs | Google Cloud access | to be filled in |
| Read the help centre content | Nothing — it is public | — |
Two GitHub accounts are in use, and only one of them can see the organisation's repositories. If a repository comes back as "not found" when you know it exists, you are signed in as the wrong one.
Test data in dev
Bookings in dev use obviously fake guest names and throwaway email addresses. Amounts appear in both yen and rupiah, so both no-decimal and two-decimal currencies are represented.
Still needed: which test cards work, whether there is a reliable test partner set up, and whether a refunded booking exists for checking the invoice document.
Running the service on your own machine
The service is written in Go. Several of its libraries are private, so a local build needs a working GitHub connection over SSH for the organisation.
Configuration comes from a file chosen by an environment setting; secrets come from the surrounding environment rather than the file.
Nobody has run this locally as part of writing the handbook, so these instructions are not tested.
What is not established yet
| Gap | Who can settle it |
|---|---|
| Who grants each kind of access, by name or by team | whoever runs it today |
| Whether a shared dev vendor account exists or everyone gets their own | product |
| Which test cards work in dev | engineering |
| Whether a test partnership exists in dev | engineering |
| Whether local setup actually works from a clean machine | anyone willing to try it |