Start with what you have
One control-plane host with Postgres 15 or newer, one or more serving nodes and a small test group. Docker Compose is the single-host evaluation path; Helm and systemd are available for the deployment you intend to operate.
Free to deploy. Support through backing.
Start with one team.
Measure a real workload.
Use your own hardware, identity provider and success criteria to evaluate StarLight. Prove the deployment you need before expanding it.
01 / Choose a bounded evaluation
One workload, with a named owner.
Choose an application such as an internal coding assistant, private chat service or document workflow. Record the model, request sizes, expected peak concurrency and data classification. Pick a checkpoint that TensorFold qualifies on your hardware.
Agree the boundary
Name the technical owner and security reviewer. Use representative, approved test data. Decide whether provider routes are permitted and which project limits apply.
Self-managed evaluation is free and does not include direct support. Deployment assistance and ongoing support are funded through agreed donations, sponsorship or project backing.
02 / Deploy a source-build evaluation
A reproducible starting point.
This guide pins the public source reviewed on 5 November 2026. Install Git, Docker and Docker Compose first. The build downloads dependencies; serving nodes also need the compatible TensorFold engine and your chosen model.
Build the evaluation control plane
git clone https://github.com/ashhart/tf-starlight.git
cd tf-starlight
git checkout 885b4967063ddabe692126f5ba3c9bdf2f6134d5
cd deploy/compose
./bootstrap.sh
docker compose build
docker compose run --rm starlight init --org "Example Corp"
docker compose up -dThe init command prints a one-time setup link. Open it, configure your identity provider and finish first-owner sign-in. For an isolated identity trial, the README describes the optional development IdP profile.
Current quick start · Pinned engine and archive hashes · Check current releases ↗
Enrol a serving node.
Before connecting a remote machine, configure the public and node URLs, TLS and network paths for that environment. The command below creates an automatic-approval token for an isolated pilot. Treat the printed token and setup links as credentials.
Create the pilot enrolment command
docker compose exec starlight starlight nodes token --pool default --auto-approveRun the command StarLight prints on the serving machine, then start starlight-node run with the engine and model configuration described in the node guide. Add the model and deployment in the console at /console.
Network and TLS requirements · Serving-node setup
Connect the test application.
Use Connect or an API key with an OpenAI- or Anthropic-compatible client. This loopback example applies when the client is on the same host; use your configured HTTPS origin for a remote client.
Connect a local test client
tensorfold-connect login --server http://localhost:8443
tensorfold-connect bridge &
tensorfold-connect env openaiConnect setup · API integration
Control-plane hosting and readiness checks
Compose is useful for a trial. For Kubernetes, review the Helm values, database, ingress and network policies. For a Linux service, review systemd, TLS and credential handling.
Use starlight doctor, health/readiness endpoints and starlight audit verify as described in the operations guide. Keep the database and master key backed up before testing upgrades or recovery.
03 / Record a representative run
Set the pass criteria before the test.
Registered users, simultaneous requests and generated tokens are different measures. Use the prompt lengths, output lengths, arrival rate and quality expectations of the application you intend to serve.
| Measure | Record during your pilot |
|---|---|
| Workload and quality | Exact model, quantisation, engine version, prompt/output lengths and task-quality acceptance cases. |
| Responsiveness | Median and p95 queue wait, time to first token and end-to-end latency at your planned peak. |
| Capacity | Successful requests, simultaneous requests, total generated tokens/s, errors by code and CPU/GPU/memory use. |
| Access and policy | Sign-in, group mapping, deactivation, project model grants, budget limits and allowed data routes. |
| Recovery | Gateway/node loss, database failover, restore and upgrade/rollback procedure. Record recovery time and any lost work. |
| Cost | Measured energy, hardware allocation, staff time, hosting, provider charges and any agreed project backing. |
Use your own measurements
Plan the cost of your workload.
Enter measured or budgeted amounts in one currency. This estimates the cost of the deployment you describe; it does not predict model speed or hardware capacity.
The planner runs in your browser and does not save or send your entries.
Calculation method and example
Monthly total = hardware cost / hardware life in months + average fleet kW × monthly hours × cost per kWh + hosting + operations + project backing + external services.
Cost per 1,000 successful requests = monthly total / successful requests × 1,000.
Illustrative arithmetic only: hardware of 12,000 over 36 months; 0.8 kW for 720 hours at 0.25/kWh; hosting 80; operations 600; project backing 250; external services 100. The monthly total is 1,507.33 in the chosen currency, or 30.15 per 1,000 at 50,000 successful requests. These are example inputs, not StarLight measurements or support prices.
04 / Make the rollout decision
Expand only after your criteria pass.
- Review the results. Compare the measured workload, quality and costs with your agreed targets. Record limitations and the exact software and hardware.
- Agree operational ownership. Name who owns identity, database and master-key backups, monitoring, upgrades and incident handling.
- Complete the applicable checks. Use the qualification record to close the hardware, identity, availability and security gates for your deployment.
- Choose your support arrangement. Operate it yourself without direct support, or agree donations, sponsorship or ongoing backing for a defined support scope and period.
Help validate real enterprise deployments
Become a StarLight design partner.
Bring a real workload and an organisation willing to share technical feedback. Help test deployment, identity integration, workload quality and ongoing operation. Improvements developed together will be published on GitHub.
- A named technical owner and a clearly scoped workload
- Hardware and an identity environment you can use for the pilot
- Agreed success criteria and willingness to report both results and issues
Self-managed pilots remain free. Direct assistance is arranged through project backing. Any public case study, customer name or published deployment result requires your agreement.
Discuss a design partnership