> ## Documentation Index > Fetch the complete documentation index at: https://docs.springwinter.dev/llms.txt > Use this file to discover all available pages before exploring further. # Can You Self-Host Temporal on Springwinter? > Understand which Temporal components fit Springwinter today, why the Temporal Service needs private stateful infrastructure, and how to deploy Workers safely. Springwinter can deploy Temporal Workers today, but the full self-hosted Temporal Service is not a first-class Springwinter resource. A production Temporal control plane needs private gRPC networking, durable persistence, coordinated server roles, migrations, backups, and upgrade discipline. *Updated October 9, 2026.* **Use Temporal Cloud or operate the Temporal Service separately; use Springwinter for application Workers.** ## What a self-hosted Temporal Service includes Temporal is more than one container. Production deployments separate or scale frontend, history, matching, and worker services. The cluster also depends on a supported persistence database and may use a visibility store, depending on the selected version and features. Temporal's official guidance says the Service should not be exposed to the open internet. Treat it like a database control plane and restrict access to trusted private networks. ## Why an ordinary Web server is not enough A Springwinter Web server is designed for public HTTP applications behind the platform's load-balancing path. Temporal clients primarily use gRPC, usually on port `7233`, and the server needs internal service discovery plus controlled access to persistence. A Springwinter Worker is replaceable application compute. It does not provide the stateful cluster lifecycle needed by Temporal Server. ## Recommended deployment options ### Temporal Cloud plus Springwinter Workers This is the simplest production path. Temporal Cloud operates the Service. Springwinter Workers execute your Workflow and Activity code in your AWS account. ### Self-hosted Temporal outside Springwinter Use the official Helm deployment on Kubernetes or build a dedicated ECS/EC2 architecture with private load balancing, service discovery, supported persistence, metrics, backups, and sequential upgrades. Connect Springwinter Workers only after private networking and authentication are proven. ### Development-only local server Use Temporal's development server for local testing. Do not promote a single development container or Docker Compose sample into production without addressing availability, persistence, security, and upgrades. ## Production readiness questions * Which database owns Temporal persistence, and how is it backed up? * How are schema migrations applied before server upgrades? * How are frontend gRPC endpoints kept private? * How many Availability Zones can fail without losing service? * Which metrics detect queue, history, persistence, and poller pressure? * How will clients rotate mTLS certificates or API credentials? * Can you load-test and upgrade without breaking running Workflows? ## Frequently asked questions A container may start, but it is not a production design. The development server does not provide the persistence, availability, secure networking, backup, and upgrade model required for durable business workflows. Springwinter can provision supported RDS database resources, but creating a database does not deploy or operate the Temporal Service, its schemas, visibility configuration, or upgrades. Run Temporal Cloud or a separately operated private Temporal Service, then deploy each Task Queue's application code as one or more Springwinter Workers. ## Sources and further reading * [Deploying a Temporal Service](https://docs.temporal.io/self-hosted-guide/deployment) * [Temporal production readiness checklist](https://docs.temporal.io/self-hosted-guide/production-checklist) * [Deploy Temporal Workers on Springwinter](/blog/deploy-temporal-workers-springwinter) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.