Get startedOperate · Serving
Create and manage deployments
Serve an evaluated model or workflow through managed, provider-backed, local, or edge infrastructure.
Source reviewed 2026-09-16. Availability depends on your installation, permissions, and compatible runtimes. A supported path is not a guarantee of model quality or production readiness.
Outcome
Create a routable production release with an identifiable artifact, runtime, health state, and rollback path.
Start here
What you need to know first
Check the inputs below before starting. If you are new, begin with the first-project guide. A dataset holds media and labels; a model produces results; a deployment makes a selected model version callable. Creating one does not create the others.
Bring these inputs
- — An eligible model or workflow version
- — Runtime image, environment, capacity, and routing configuration
Expected output and limits
- — A versioned deployment
- — Endpoint/device assignment, health, and rollback history
Core workflow
Choose the release
Select the model or workflow version. Score Studio finds and pins its newest qualifying held-out test; failed or missing evidence cannot receive traffic.
Select a target
Choose managed cloud, a connected provider, a local runtime, or a registered device.
Configure serving
Set warm replicas, maximum replicas, per-replica concurrency, request timeout, routing, environment, and runtime-specific options. Start below the measured saturation point and repeat the external-client load test after changing capacity.
Verify the endpoint
The deployment overview shows Start, Verify runtime, or Use endpoint according to its state. Pause stays directly available for running endpoints; More contains Stop, rollback, and routine verification. Verify runtime health, then create a key restricted to this deployment from API quickstart. Test the endpoint from a separate client, retain request IDs, confirm the pinned model version, and exercise authentication, validation, throttling, and overload behavior. Actions that run away from a form (verifying or deleting a deployment, archiving or deleting dataset files, changing a dataset's visibility) report a failure through a notification in the corner of the page; the page itself stays usable.
What this surface supports
Managed APIs
Deployment-scoped credentials
Correlated success and error logs
Provider-backed serving
Local runtimes
Edge targets
Expert section
Contracts, signals, and failure modes
Use this section when you are defining acceptance criteria, automating the surface, or reviewing whether its output is safe to promote downstream.
Quality and operating signals
- — Readiness and liveness
- — Traffic, saturation, and errors
- — Latency and cost per inference
Common failure modes
- — Missing runtime dependency
- — Insufficient capacity
- — Credential or network failure
- — Health check that does not exercise inference
Expert release checklist
□ Inputs and dependencies are pinned to immutable versions.
□ Acceptance metrics include critical classes and operating slices.
□ Failure, retry, cost, and rollback behavior are understood.
□ The resulting artifact has an owner and a downstream review path.
Engineering safeguards
- — A stopped Score deployment can be prepared without spend; traffic waits for a passing exact-version test
- — Runtime health and model-quality evidence remain separate
- — Authenticated endpoint failures retain the response request ID in deployment logs
- — Rollback keeps artifact history