What is Nomaflow
Nomaflow is the scheduler and orchestration engine that ships with the Liberty Framework. It runs inside the framework process — no separate worker, no broker (Redis / RabbitMQ), no companion daemon. The framework you've already installed for screens and dashboards now also schedules cron jobs, runs ETL pipelines, mirrors LDAP directories, fans out HTTP calls and lets operators watch every run live from a UI.
If a team already has the framework, they have Nomaflow. If they don't, the framework is the install path.
What it solves
Most teams that operate internal applications end up needing the same kind of "background work" infrastructure:
- A nightly database refresh that pulls data from an operational store into a reporting store.
- A periodic API pull from a third-party service, with retry on failure.
- An LDAP / Active Directory sync that mirrors users + groups into the application.
- A cleanup job that prunes old records, archives PDFs, deletes expired sessions.
- A conditional flow that runs only when something specific happened (a file landed, a count crossed a threshold).
- A manual one-off that an operator triggers from a button after a release.
Doing this without Nomaflow usually means cron tabs scattered across hosts, Python scripts in different repos, no shared retry logic, no single place to see "what just ran". Doing it with Nomaflow means one catalogue of jobs, one history of runs, one live log tail, all in the same UI as the rest of the application.
At a glance
What you can build
| Pattern | What it looks like with Nomaflow |
|---|---|
| Scheduled database sync | Cron at 02:00 → SQL Copy step from source pool to target pool → success notification. Recipe. |
| External API pull | Cron every hour → HTTP step with bearer auth → Python step transforms the payload → SQL write into target table. Recipe. |
| LDAP / AD mirror | Cron every 4 hours → LDAP Sync step → upsert into the users table. |
| Conditional cleanup | Cron daily → SQL Query to count old rows → conditional Python step deletes them only past a threshold. Recipe. |
| Manual one-off | No schedule → operator opens Jobs page → ▶ Run now with parameters → watches the live log. |
| File watcher → batch | Cron every 5 minutes → Python step lists a folder → for each new file, SQL Copy + archive move. |
| Smoke test | Cron every 5 minutes → HTTP step against your own healthz → email alert if it fails 3 times in a row. |
The pieces are deliberately small (a step does one thing). The pipelines compose them; the run history surfaces what happened.
When to use Nomaflow
| Reach for Nomaflow when… | Reach for something else when… |
|---|---|
| Workloads are install-scoped and don't cross multiple systems. | Workloads span a dozen services and need a global DAG view. |
| The whole pipeline finishes in seconds to minutes. | A single step takes hours and needs autoscaling. |
| Cron + linear steps + retry is enough. | You need dynamic task expansion, fan-out / fan-in DAGs, distributed compute. |
| You want one tool, one UI, one log stream. | You already run Airflow / Dagster / Prefect for everything else and a second tool is overhead. |
| You'd otherwise hand-write a Python script + a systemd timer. | You'd otherwise hand-write a Kubernetes CronJob with sidecars. |
The framework's design point is "the operational glue most internal apps need" — not "every orchestration use case". For the 80 % case, it removes a lot of pipe-laying.
How it fits inside the framework
Nomaflow uses the framework's connectors to reach databases and APIs (the same connectors your screens and dashboards use), the framework's permission model to gate who can trigger what, the framework's encryption layer to hold credentials safely, and the framework's Settings UI to define everything. There's no "Nomaflow database" to install, no "Nomaflow user accounts" to manage.
| Framework piece | What Nomaflow gets from it |
|---|---|
| Connectors (SQL / HTTP / LDAP) | Reach data sources and APIs through declared queries / endpoints. |
| Pools | Database connections. |
| Authentication + roles | job:<name> permission gates per role. :session_user for audit on triggers. |
| Encryption | Connector credentials, webhook URLs, OAuth secrets — all 🔒 encrypted. |
| Settings UI | The Jobs builder + step editor live there. |
| Socket.IO | Live updates on run state, step transitions, log tail. |
| Notifications channels | Slack / email / webhook — defined once at framework level, used by every job. |
The Liberty Framework documentation covers these underlying pieces; Nomaflow's documentation focuses on what you build with them.
Tour of the documentation
| Page | Read it to… |
|---|---|
| Getting started | Build a first scheduled job in 10 minutes. |
| Concepts | Understand the job / run / step / schedule mental model. |
| Jobs → Catalogue | Browse, search, trigger jobs from the Jobs page. |
| Jobs → Create a job | Walk through the job builder. |
| Jobs → Schedules | Cron syntax, intervals, calendar preview. |
| Steps | What each step type does (SQL Query, SQL Copy, Python, HTTP, LDAP Sync). |
| Runs → History | The Runs page — filter, status, drill into a run. |
| Runs → Troubleshoot | When a run fails — how to find out why. |
| Workflow recipes | Three end-to-end patterns ready to adapt. |
| Custom Python steps | Drop in your own logic when declarative steps aren't enough. |
| Notifications | Slack / email / webhook on outcomes. |
| Administration | Multi-replica scheduler, retention, restart behaviour. |
Where Nomaflow doesn't go
A short honesty list, so expectations match what's there:
- No DAG of jobs with parallel branches. Steps inside a job are linear; you can chain jobs through Dependencies, but the model is "step by step" not "graph". Most operational workloads fit that fine.
- No autoscaling worker pool. The scheduler runs in the framework process. Heavy parallel batches (thousands of concurrent steps) are not its strong suit.
- No data lineage / catalog. Nomaflow knows which steps ran; it doesn't track what columns flowed from which source to which target. Use a dedicated catalog tool if that matters.
- No SaaS-grade backfill UI. You can replay a finished run; you don't get "re-run for every day in the past 90 days" out of the box (write a Python step for that).
These are tradeoffs, not gaps to fix — the design point is the small, install-scoped case.
Ready to go
→ Getting started — your first scheduled job in 10 minutes.
Or if you prefer to read first: Concepts for the mental model, then Jobs → Create a job for the walkthrough.