# HOSTING — your task

## What you're being asked to do

Stand up a **temporary, internal test version** of IRIS Chat so the project team
can test the app on their own phones before it's ever submitted to an app store.
There are two things to host:

1. **The proxy server + its database** (`server/`) → gives back a **server
   address**.
2. **The admin console** (`admin/`) — a single static web page → gives back an
   **admin console link**.

The doctor phone app itself isn't hosted by you; it gets installed on test phones
in a later step, pointed at the server address you provide.

> **This is temporary test hosting, not production.** It exists only for the
> testing period and can be torn down afterwards. The proper production setup is a
> separate, later phase with its own runbook (`IT_RUNBOOK.md`, not yet written).
> Don't over-engineer this; a small internal host is the goal.

## The step-by-step is in TEST_HOSTING.md

The exact, click-by-click instructions — deploy the `server/` folder, run
`python3 proxy.py`, set the environment variables, serve the one static admin page,
verify with the `/health` check — are in **[TEST_HOSTING.md](TEST_HOSTING.md)**.
This document is the *why* and the *rules*; that one is the *how*. Follow
TEST_HOSTING.md for the mechanics; make sure everything below is true before you
expose anything.

The server needs only **Python 3.8+** and **no installed packages** (standard
library only). It reads all its settings from environment variables / a local
`.env` file — see `server/.env.example`.

## Non-negotiable requirements

These protect the exact thing the whole product exists to protect. Please treat
them as hard gates, not suggestions.

**1. The API key lives only as a server secret.**
The Anthropic API key goes into the host's secret store / environment (or the
server's `.env`, which is git-ignored) — **never** committed to the repository and
**never** sent in an email or chat message, to anyone, including the project team.
Generate a **dedicated, spending-capped test key** you can disable the moment
testing ends. The server refuses to start without a key, by design.

**2. Set real admin-console logins before the console is reachable.**
The console ships with **public demo logins** (`admin`/`admin-demo`,
`viewer`/`viewer-demo`) that are visible in the repository. You disable them by
setting the `IRIS_ADMIN_USERS` environment variable to real accounts (format and
details in TEST_HOSTING.md). **Do this before the console is reachable by anyone.**
If the console would be live with the demo logins still working, stop and fix that
first. These real credentials are secrets too — host environment only, never the
repo, never a message.

**3. The demo *doctor* login cards must be replaced before real doctors.**
The doctor app also contains fictional demo sign-in cards (e.g. card `IRIS-2607` /
PIN `1234`). For *this internal test* they're fine — they're how your testers sign
in. But they are baked into the app itself (not a server setting), so replacing
them with a real sign-in is an **app change the project team owns** before any real
doctor uses it. Flagged here so it's on everyone's radar; you don't set this.

**4. Do not turn on request-body logging.**
Whatever host or proxy you put in front of the server, **do not enable logging of
request bodies.** The message bodies are the coded reports; capturing them would
defeat the point and create exactly the record the on-device masking exists to
avoid. Event/access logs (path, status, timing) are fine — content logs are not.
The server itself already logs events only, never content; keep any surrounding
infrastructure the same way.

**5. The admin console must not be publicly reachable.**
It's a back-office tool. Put it behind the company network / VPN / IP allow-list /
SSO — whatever your standard internal-only control is. It should not be findable or
loadable from the open internet, even with a login in front of it.

**6. The database must sit inside company controls.**
The server's database holds the filed reports **and the roster** — the master table
that maps each code back to a real product, hospital, and doctor. That roster is the
one thing that could turn codes back into names, so the database must live on
infrastructure the company controls, with your normal access controls and backups —
not a third-party service outside those controls. Put it on a persistent disk so
test data survives a restart (see TEST_HOSTING.md).

## What to send back

When it's up and the requirements above are met, reply to the project owner with
exactly two things:

- **The server address** — e.g. `https://iris-proxy.internal.ourcompany.com`
- **The admin console link** — e.g. `https://iris-admin.internal.ourcompany.com/...`

**Not** the API key. **Not** the admin passwords. Just the two links. Those unblock
the on-our-own-phones testing step.

## Keeping it current

Improvements to the app come from the project team through the repository; you host
copies of it. When they send an update, you re-deploy from the repo (pull + restart
the server; re-upload the admin page). You never edit the hosted copy directly. The
update loop is spelled out in TEST_HOSTING.md. See [FAQ.md](FAQ.md) for who owns
what.