Temporal persists progress as workflow history
Temporal records an append-only event history for each workflow execution. A worker replays that history through workflow code to rebuild state, then emits commands for the next timer or activity. If the worker disappears, another can continue from the recorded history. The server does not run arbitrary application functions itself. It coordinates tasks and stores enough state for user-hosted workers to resume them.
That model suits payment lifecycles, provisioning, order fulfillment, and other processes where partial completion matters. Our checkout contained about 1,012,819 source lines across 3,835 files, which reflects how much machinery sits below the SDK surface. The benefit is removing custom retry columns and recovery daemons from each product team. The cost is learning Temporal's execution rules and operating a system whose job is to preserve application progress.
Workflow code must replay to the same decisions
Temporal separates workflow definitions from activities. Workflow code coordinates and waits. It must be deterministic because the SDK may replay old events through newer code. Activities perform database writes, API calls, and other side effects. Since an activity can be retried, the architecture guidance says it should be idempotent or explicitly non-retryable. This is a programming model, not an annotation added after ordinary background code is written.
Versioning deserves design work before the first major workflow change. A deployment may have executions started under older logic while new workers run different code. With 467 Go packages installed in our server build, repository contributors face a large Go system, but application developers mainly face their chosen SDK and its replay checks. Teams should place business decisions in workflows, side effects in activities, and test histories from production-compatible versions during changes.
What happened when we ran it
We cloned commit 6805cae into an unprivileged Go 1.24 Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The 39.9 MB checkout had 3,835 files and about 1,012,819 source lines. The repository included 20 CI workflow files and a tests directory. It did not have a root Dockerfile. The harness evaluated dependency installation, the server build, and the configured Go test targets.
Go dependency installation succeeded in 76 seconds and brought in 467 packages. The build completed in 278 seconds. Tests ran for 468 seconds and ended with exit code 1: 13 passed and 2 failed out of 15. The final lines show go.temporal.io/server/tools/tests.(*PostgresqlSuite).TestPostgreSQLConnTestSuite and a stack through testify/suite, followed by package failure.
The provided log tail does not contain the failed assertion, database error, or connection message. It would be guesswork to blame missing PostgreSQL, permissions, or server code from that fragment alone. We can say the measured suite was mostly successful and its two failures were in the PostgreSQL CLI test package. Contributors should reproduce that target with the repository's documented test services before deciding whether the container or code caused it.
A local dev server hides the production topology
The README's first run is pleasantly short: install the Temporal CLI and start its development server. Sample workers in Go or Java can then connect, and a web interface appears on the documented local port. This is enough to learn workflow, activity, signal, query, and retry behavior without building the server from source. Most application developers should start there or use Temporal Cloud.
Self-hosting means operating Frontend, History, Matching, and internal worker services with persistence underneath them. History shards own workflow executions. Matching holds task queues polled by SDK workers. Release and database schema upgrades need an order, while namespaces, retention, visibility, TLS, authorization, metrics, and backups need explicit policy. Our 278-second source build says little about that operational work; a failure drill and restore test say much more.
Persistence behavior is the operational risk
Temporal's value depends on its history and current-execution records remaining consistent. Issue 10841 reports a Cassandra deployment where an orphaned current-execution pointer caused SignalWithStart calls for one workflow ID to hit client deadlines indefinitely. An administrative deletion cleared the pointer in that report. The issue concerns an unusual corrupt state, yet it shows why persistence repair, compaction, backups, and admin tooling belong in a self-hosting plan.
PostgreSQL operators have different edges. Issue 11780 says the auto-setup template does not expose connection attributes for PostgreSQL, including a connection timeout, and describes a reconnect hanging while holding a shared database handle. Our own 2 failed targets were also in a PostgreSQL test package, though the log does not connect them to that issue. Search the tracker by database and pinned server version rather than treating the combined 930 issues and pull requests as a defect count.
Current security releases need careful rollout
Release v1.31.2 was published on July 8, 2026, and addresses CVE-2026-5724 in replication streaming authorization. The release warns that replication users may see connection errors and provides a dynamic-config opt-out, while noting the security implications of using it. Multi-cluster operators should test the authorization path and avoid copying an opt-out into permanent configuration just to finish an upgrade.
GitHub recorded a push on August 26, 2026, with issue activity the day before. The server is active even though the latest tagged release was several weeks earlier. Temporal remains the right shortlist choice when durable state is the requirement and teams accept deterministic workflows, idempotent activities, and worker operations. If a task can safely start over, a normal queue will be cheaper to learn and run.