Architecture and security
Three parts, inside your network.
Written for the people who will approve the platform entering the environment — IT, DBA and security.
Portal
The web application where you register, validate and schedule. It does not execute processes.
Executor
A containerised service that polls the queue and runs the routines. There can be several, on different machines. (In the code and the logs it appears as Worker — it is the same component.)
Orchestration HUB
Holds definitions, permissions, the queue and the history. It is the only channel between portal and executor — and it runs on the database you choose.
The HUB
Why the central component is a database.
It is an architectural decision, not a cost saving. Worth explaining, because evaluators usually expect a dedicated service in its place.
Nothing extra to operate
No message queue to install, monitor, update and secure. In a mid-sized company’s operation that is not a saving on infrastructure — it is a saving on people.
Transactional consistency
The queue and the data live in the same transaction. A broker would bring dual writes and the exactly-once delivery problem; this design does not have it.
Recovery is a query
A run interrupted by a crash is found and re-queued by reading a table — not by reprocessing an event log.
Your DBA already knows how to run it
Backup, monitoring, replication and high availability for the HUB are the procedures your organisation already has, in the tool it already uses.
Where the HUB runs
On your server, or on a managed cloud. You decide.
It is the same installation — one configuration line changes. The choice has consequences, so they are written here, not in the small print of the contract.
HUB on your server
Data and control stay entirely inside your network.
Ganha: it works with no internet at all, and nothing leaves the building.
Assume: high availability for the HUB is whatever you build.
HUB on a managed cloud
Azure SQL, Amazon RDS, Cloud SQL or Oracle Autonomous — the same providers, via connection string.
Ganha: high availability for the HUB becomes your provider’s.
Assume: the executors need a link to it — it stops working offline.
The executors stay where the work is: next to the legacy ERP, the branch office’s Firebird, the file share. It is the HUB that can move to the cloud — not the execution.
Security
Where the secrets live.
Encrypted credentials
Database and SMTP passwords are encrypted with the installation’s protection keys. No screen shows them once saved, and they never appear in full in a log.
Injection with no password in the code
The script receives connection and credential as environment variables. No plaintext password inside the process — and what the step receives is an explicit declaration, checked at save time.
Layered authorization
5 user profiles, per-process assignments, restricted tags and hidden mode. The check is on the server, on every action — hiding the button was never considered protection.
Controlled import
Importing a package brings in code the executor will run. That is why it is one item at a time, with size limits and refusal of malicious content — never in bulk.
Operation
What runs on its own, and where.
| Routine | Frequency | Where it runs |
|---|---|---|
| Queue execution | every 5 s | all executors |
| Schedule trigger | every 30 s | all executors (once only) |
| Heartbeat | every 1 min | all executors |
| Execution data cleanup | every 1 h | all executors |
| History and metrics purge | local midnight | primary executor only |
| Recycle bin purge | every 6 h | primary executor only |
Continuity
A portal that is down does not stop your routines.
It follows directly from the architecture: the queue lives in the database and the executors are what run things, as separate processes. If the portal goes down at 3am, schedules keep firing and the queue keeps being consumed — you lose the screen, not the operation.
Executors
Several on the same database, natively. Contention over the queue is resolved in the database itself, so an executor can come and go without coordinating anything — and a run interrupted by a crash is recovered when it returns.
Native — nothing to configure beyond starting another executor.
Database
It is yours. Use the high availability you already have — cluster, replica or managed service. The platform does not interfere.
Your standard — 5 databases supported as the control database.
Portal
One instance per installation is the tested topology. Continuity comes from the infrastructure you already run: a hypervisor cluster or container orchestrator restarts the portal on another node, as it does with any other application of yours.
Your infrastructure — Proxmox, Hyper-V, VMware, Kubernetes.
What does not exist is autoscaling: the platform does not start or stop executors by itself according to load. How many executors run is your decision, and the cost does not change with volume.