Waymark's developers introduced their open-source background workflow engine in a November 5 Show HN post, offering Python teams a way to save a job's progress without replaying its orchestration code. The project documentation describes a compiler and Rust runtime backed by Postgres. Waymark is in early alpha, with no backward-compatibility guarantee before 1.0.0.
The distinction matters when a background process dies halfway through an import or an agent task. Waymark compiles a workflow the first time it runs or is scheduled, then saves the program and its progress in Postgres. That design comes with a language boundary: the workflow can use only the Python patterns its compiler understands. This account examines the published documentation checked on November 7, rather than a tested deployment.
The workflow coordinates; actions do the work
The repository's example separates a welcome-email job into actions that fetch users and send messages, plus a workflow that filters the users and dispatches emails in parallel. The job is queued through Postgres and executed by a separate node, so the web request doesn't run the whole batch itself.
According to the design explanation, Waymark parses the workflow's syntax tree and stores a compiled program. Its Rust runtime executes that program, dispatching actions to workers and recording progress. Network requests and randomness belong inside actions. Developers still have to make those actions safe to repeat after a failure.
For a team evaluating the project, this puts two questions ahead of benchmark numbers: can its coordination logic fit the supported subset, and can its external effects tolerate another attempt?
Familiar Python has specific limits
The control-flow reference documents branches and loops, along with parallel calls through asyncio.gather. It also lists ordinary Python constructs the workflow compiler currently rejects. These include try/finally, f-strings and chained comparisons. Cleanup that requires finally must live inside an action for now.
There are runtime differences to inspect too. The same reference says models and dataclasses become dictionaries inside workflows, while tuples become lists. Some dynamically obtained values can encounter limitations that static checks haven't caught. A successful compilation therefore doesn't establish that a workflow preserves every behavior of its original Python code.
Postgres simplifies the topology, not upgrades
The deployment guide requires an application, Waymark nodes and Postgres 14 or later. Nodes claim workflow instances through database leases. If a node crashes, another can resume its saved work after the lease expires. An action that was in flight can be delivered again, making repeat-safe behavior an operational requirement.
Version upgrades require downtime. The guide says rolling updates aren't supported and tells operators to snapshot the database before migration: an older version refuses the migrated schema. Teams considering a pilot should include that interruption in their deployment plan.
The next useful evidence is whether the compiler's documented restrictions and runtime differences shrink as the alpha develops. For now, the maintainer's compatibility warning makes a disposable pilot a more defensible next step than migrating an important job on the strength of the launch presentation.