Use this checklist when a small application team wants one model-facing API, reusable workflow behavior and inspectable runs. For the architecture and fit decision, read A self-hosted AI gateway for small application teams.
This is a source-grounded evaluation procedure, not a completed installation test. The endpoint contract is checked against v0.4.1; UI labels and provider support must be verified on your installed version.
1. Record the test boundary
- Choose an isolated non-production deployment and synthetic data
- Record source revision, actual container image tags/digests and provider plugin versions
- Record the client version, API protocol and features you need to support
- Set an acceptable test-usage budget with the provider account owner
- Keep application keys, provider credentials and installer output private
Use the official installation instructions and the deployment guide for your release. The moving installer obtains main deployment files and can use latest images; it is not a pinned v0.4.1 installation. Confirm services actually started rather than assuming configuration-file creation means readiness.
2. Publish the smallest model path
- Configure one authorized provider/model and confirm it is usable
- Configure a minimal AgentFlow with Start and LLM nodes
- Set a public model name such as
first-requestand publish its API - Use the application’s API key, not an upstream provider key or root password
- Check the installed API panel for the endpoint and supported request fields
The stable gateway fixture and bootstrap code establish the public-model and application-key contract. They are developer fixtures, not a replacement for deployment instructions.
3. Send one synthetic request
See the minimal curl request. It uses POST /v1/chat/completions, Bearer application authentication, the published model name and stream: false.
- The HTTP response is successful
- The assistant answer is non-empty
- The corresponding run is visible in Log
- Prompt/time, model call and final answer can be matched to the request
- Missing usage fields remain marked unknown
For easier manual correlation, put a unique synthetic marker in the test prompt. Do not assume arbitrary metadata fields are accepted or that a client user identifier creates a conversation thread.
4. Test only the additional features you need
Evaluate streaming, tool calls, images, cancellation and concurrent requests separately if your client uses them. A text-only success does not prove these paths work.
Next, choose one documented extension:
Compare the same representative prompts before and after. Include failures and repeated attempts in your latency and usage review. Do not promise automatic failover or cost savings merely because multiple models are configured.
5. Write a decision receipt
Record the version, client/protocol, successful cases, failed cases, unavailable fields and operational work remaining. A useful result is either “this specific path meets our criteria” or a clear list of blockers.
Before real data or production exposure, assign owners for access control, HTTPS, retention, backups, upgrades and provider data handling. A self-hosted gateway can still send requests to cloud providers.
If the next need is a team investigation queue, continue with Prototype an AI Run Review App. For cost inspection, use the Token BOM guide.