Temporal - Secure Durable Execution Engine AMI by cloudimg

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

Temporal is a popular open source durable execution engine. Your application defines Workflows and Activities in your own code and runs them against the Temporal server, which persists every execution's full event history so work survives process and host failures and resumes exactly where it left off. This AMI delivers a fully installed, security-hardened Temporal appliance - the Temporal server, its Web UI and a bundled PostgreSQL - so a working durable-execution backend is operational within minutes of launch, running privately in your own AWS account.

This image eliminates the manual work of wiring the Temporal server to a database, running schema setup and namespace registration, standing up the Web UI, and hardening the whole stack. Temporal's open source Web UI has no authentication of its own - anyone who can reach it can read every namespace, workflow input, result and full execution history. This image never leaves it exposed: the Temporal frontend and the bundled PostgreSQL are bound to the loopback interface only, and an nginx reverse proxy fronts the Web UI with HTTP Basic authentication whose password is generated uniquely on each instance's first boot. Launch the instance, read your unique credential, and start running workflows.

The Temporal server, its Web UI, an admin-tools container and a bundled PostgreSQL run as official upstream containers, pinned by image digest, orchestrated by Docker Compose under a single systemd unit. The Temporal frontend (gRPC) and the Web UI publish to the loopback interface only; PostgreSQL is never published to a host port. An nginx reverse proxy on port 80 fronts the Web UI, enforcing HTTP Basic authentication and upgrading the connection for the live UI stream. On first boot the image initialises a clean database, applies the Temporal schema, registers a default namespace, and generates a unique database password and a unique Web UI password - nothing is baked into the image.

This image follows a defence-in-depth approach:

• Network isolation: the Temporal frontend and the bundled PostgreSQL bind exclusively to the loopback interface; only the nginx reverse proxy on port 80 and SSH are reachable
• Authentication enforced: every request to the Web UI and its API is authenticated - nothing is served anonymously except an unauthenticated health endpoint for load-balancer probes
• No default or shared credentials: cryptographically random Web UI and database passwords are generated on each instance's first boot and written only to a root-only file
• Clean state per instance: the captured image ships no database, workflows or credentials; a fresh database, schema and default namespace are created on first boot
• Pinned runtime: every container is version-locked by image digest
• Automatic restart: systemd monitors the stack and restarts it on failure

Buyers requiring formal compliance documentation should contact cloudimg to discuss specific requirements.

• Reliable microservice orchestration: Model multi-step business processes - order fulfilment, provisioning, refunds - as Workflows whose state survives crashes and deploys, replacing brittle queues and cron glue with durable, observable executions
• Long-running and human-in-the-loop processes: Run Workflows that wait days or weeks - approvals, onboarding, subscription lifecycles - with timers, retries and signals handled by the engine and every step visible in the Web UI
• Data and AI pipelines: Drive idempotent, automatically retried pipeline stages and scheduled recurring jobs from Temporal, inspecting each run's full event history when something needs debugging

Deploy on any EC2 instance type; larger instances handle more concurrent workflow executions. Use the unauthenticated health endpoint with an Application Load Balancer for availability monitoring, place the instance in a VPC subnet with security-group control, forward logs to CloudWatch, and snapshot with EBS or AWS Backup to protect your workflow history.

Launch a small instance type such as t3.medium to validate the product at minimal cost. The AMI is fully functional on any supported instance size, so you can explore the Web UI, connect SDK workers, and run test workflows before scaling up for production workloads.

Read your credential from the root-only file, open the Web interface, sign in, and explore the pre-registered default namespace. Point your SDK workers at the frontend, start a workflow, and watch its status and event history update live in the Web UI. For a guided walkthrough or help connecting your first workers, contact cloudimg support at any time.