Category: Blog

Today we are thrilled to announce NovaPulse Flow 2.0 — the biggest update to our event-driven orchestration engine since its initial launch. Flow 2.0 introduces parallel execution, conditional branching, and a completely redesigned visual workflow editor.

What is New in Flow 2.0

Parallel Fan-Out

Flow 2.0 supports native parallel execution with fan-out and fan-in patterns. Split a workflow into parallel branches, process data concurrently across hundreds of workers, and aggregate results — all with automatic error handling and configurable concurrency limits. Each parallel branch independently scales to zero when idle.

Conditional Branching

Workflows can now branch based on runtime conditions using a powerful expression language. Route events to different processing pipelines based on payload content, metadata, time of day, or any custom logic. Combined with parallel fan-out, this enables sophisticated event processing topologies that were previously impossible without custom code.

Visual Workflow Editor

The new visual editor lets you design, test, and deploy workflows without writing a single line of YAML. Drag and drop steps, connect triggers to actions, preview execution paths, and deploy to production — all from your browser. For teams that prefer code, the YAML-first approach remains fully supported.

Sub-Second Cold Start

Flow 2.0 achieves sub-second workflow activation times, even for workflows that have been idle for days. When an event arrives, the entire workflow graph is thawed and ready to process within 800 milliseconds. Combined with our scale-to-zero pricing, this means you truly pay only for the compute time your workflows actually use.

Availability

NovaPulse Flow 2.0 is available today for all existing Flow customers at no additional cost. New customers can start with our free tier, which includes 100,000 workflow executions per month. Visit our Products page to learn more, or contact our sales team for enterprise pricing.

When we started building NovaPulse, one of our earliest architectural decisions was choosing a container runtime. Docker was the obvious choice — it is what everyone uses, right? But after months of testing, we made the unconventional decision to build on systemd-nspawn instead. Here is why.

The Problem with Daemons

Docker requires a long-running daemon process (dockerd) that manages all containers on a host. This creates a single point of failure — if the daemon crashes, every container on the host goes down. For a platform built around scale-to-zero, where containers are constantly being frozen and thawed, daemon reliability is critical. With systemd-nspawn, each container is a direct child of PID 1 (systemd). There is no intermediary daemon. If one container crashes, nothing else is affected.

Native cgroup Integration

Our scale-to-zero technology relies heavily on cgroup v2 for freezing containers at the kernel level. systemd-nspawn containers are native systemd units, which means they get first-class cgroup management out of the box. We can freeze a container with a single systemctl freeze command, and the kernel handles the rest — no custom cgroup manipulation needed.

Simplicity and Debuggability

systemd-nspawn is a single binary with a straightforward set of options. There is no image layering system, no build cache, no complex networking overlay. It boots a full Linux userspace in a namespace — and that is it. When something goes wrong, you can debug it with standard Linux tools: journalctl, systemctl, nsenter, machinectl. No need to learn a separate ecosystem of Docker-specific debugging tools.

The Trade-offs

This choice was not without trade-offs. We had to build our own image distribution system (which became NovaPulse’s content-addressed storage layer). We had to implement our own networking stack. And we lost access to Docker’s massive ecosystem of pre-built images — though we built a compatibility layer that can import OCI images into nspawn containers.

But the benefits — no daemon, native cgroup integration, kernel-level freeze/thaw, and radical simplicity — made systemd-nspawn the right foundation for what we are building. Sometimes the unconventional choice is the correct one.

Here is a number that should make every CTO uncomfortable: 80% of development and staging containers sit idle at any given moment. That is not a guess — it is what we see consistently across the hundreds of organizations we work with.

The Hidden Cost of Always-On

The cloud promised pay-for-what-you-use pricing, but the reality is different. Most teams provision containers for peak load and leave them running 24/7. A typical mid-size engineering organization runs 200-500 containers for development, staging, QA, and demo environments. At an average cost of $50-100/month per container, that is $10,000-50,000/month — and the vast majority of those containers are doing nothing most of the time.

Why Traditional Autoscaling Falls Short

Traditional autoscalers can scale down to one replica, but they cannot scale to zero. There is always at least one instance running, waiting for traffic that may never come. Serverless functions solve this for stateless workloads, but they impose cold start penalties of 1-10 seconds — unacceptable for interactive applications, APIs, and development environments.

The Scale-to-Zero Approach

At NovaPulse, we take a fundamentally different approach. Instead of terminating idle containers and cold-starting new ones, we freeze them at the kernel level using cgroup v2 freezer. A frozen container uses exactly 0% CPU and costs nothing to run — but its memory state is preserved. When a request arrives, the container thaws in 11 milliseconds on average. No cold start. No re-initialization. No lost state.

The Numbers

Our customers typically see 85-94% cost reduction on non-production environments. A company running 300 containers at $75/month each ($22,500/month) might see their bill drop to $1,350-3,375/month — savings of $19,000-21,000 per month. Over a year, that is over $230,000 returned to the engineering budget. Scale-to-zero is not just a technical optimization. It is an economic imperative.