Repository-backed demo/runtime configuration.
Move from repository to runnable AI without losing the evidence chain.
Zippri connects application/tool repositories to Space configuration, compute and training jobs, running managed endpoints and an interactive Playground. Runtime configuration does not bypass verification, production authority or provider capacity rules.
Zippri Spaces
Application and tool repositories can define framework, entrypoint, hardware intent, visibility and scaling preferences. A Space can bind to an existing managed deployment, but deployment verification and production approval stay separate.
Provider-neutral governed compute and training work.
Interactive testing of running managed endpoints.
Capacity policy without falsely claiming unsupported provider autoscaling.
Jobs and training
The existing compute fabric tracks queued, approved, running and completed GPU/CPU work with wallet and provider boundaries rather than hiding resource consumption.
Playground
The Playground discovers compatible running deployments and invokes the proven Zippri runtime contract so teams can test an asset without copying endpoint credentials into another application.
Inference profiles
Endpoint profiles persist min/max replica intent, scale-to-zero request, idle timeout, concurrency and request timeout. Actual elasticity is enforced only when the selected provider/runtime advertises that capability.
Common questions about Spaces, Jobs & Playground
Does creating a Space deploy an application automatically?
No. Space metadata is separate from deployment authority. A verified managed deployment can be bound later.
Does Zippri currently claim OpenAI-compatible chat completions?
No. The proven runtime contract is Zippri /v1/invoke unless a provider/runtime explicitly supports another contract.
Can jobs use external GPU providers?
The compute architecture is provider-neutral. Live capacity depends on formally connected and healthy providers.