Skip to content
EN-US
Talk to a specialist

The solution

How it works, from setup to history.

The pieces of the platform, in the order you will use them.

The four building blocks

These four are all you need to build any routine.

Job

A process. It is what you schedule, run and watch.

Step

One stage of the process: SQL, script, data copy, backup. Each one decides what to do if it fails.

Schedule

When it runs. Registered separately, reusable, with an explicit time zone.

Executor

The service that runs your routines on your own server. It is separate from the portal, and there can be several — on different machines, close to where the data lives.

Step types

What you build on screen, and what needs a script.

The difference is worth knowing: it tells you whether you need someone who codes.

🗃️

SQL

A query or stored procedure on any of the connected databases. The result can feed the next step.

🔁

Data copy

Source, target and field mapping on screen. Full or incremental load, without a line of code.

💾

Database backup

A scheduled, compressed dump with its own retention — and an alert when it fails.

🐍

Python

This is where any system with an API comes in — Salesforce, Dynamics, HubSpot, your in-house ERP, an internal service. Connections and credentials arrive ready as environment variables, so the script never carries a password.

No catalogue, no ceiling: there is no ready-made connector to drag in — in exchange, no integration is out of reach and there is no extra module to buy.

⌨️

Shell / PowerShell

The same, for those who prefer a system script. SFTP, SMB and rsync already ship in the executor image.

🔗

Shared command

Write it once, use it in several processes. Versioned, with explicit synchronisation.

Files and Python

A spreadsheet is a data source, not an attachment.

A good share of the world’s real ETL starts in an Excel file somebody exports. Here it comes in through a Python step — with pandas and openpyxl already installed on the executor and the target connection already injected — and becomes a clean load into the database, at the agreed time, with history and an alert when it fails.

Excel

.xlsx read directly, with no manual conversion and nobody opening a spreadsheet to save it as CSV first.

Ready in the image: pandas + openpyxl, nothing to install.

CSV and text

The Python standard library, or pandas when the file is large and needs treatment.

JSON, XML and Parquet

The first two natively; Parquet through pyarrow, also already in the image.

Any API

REST, SOAP, the internal service down the hall. The credential arrives as an environment variable.

ETL or ELT — your call

Transform in Python before writing, or dump it raw and transform in SQL afterwards: the platform does not impose the design. What it gives you in both cases is what a loose script lacks — a schedule, order between steps, history, an alert when it fails and control over who can touch it.

Between steps

What one step hands to the next.

Success and failure

Each step chooses: stop, continue to the next one, or jump to a specific step.

Data

The result of a query becomes a variable in the next step — including in a loop, one execution per row.

Dependency and chaining

A process can wait for another, or trigger the next one when it finishes cleanly.

Frequently asked questions

What people ask before booking the call.

Can it load an Excel spreadsheet into the database automatically?
Yes. Loading Excel (.xlsx) and CSV is done by a Python step, with pandas and openpyxl already installed on the executor and the target connection already injected — the script carries no password. The routine runs at whatever time you schedule, with history and an email alert when it fails.
Can it copy tables between different databases?
Yes, and without writing code: the data copy step has source, target and field mapping on screen, with full or incremental load. Source and target can be from different vendors — from Oracle into PostgreSQL, for example.
Which databases does it talk to?
Seven for execution: Oracle, SQL Server, PostgreSQL, MySQL/MariaDB, Firebird, DB2 and ODBC. The platform’s own control database can be SQL Server, MySQL, PostgreSQL, Firebird or Oracle — you use what you already have.
Do I need to know how to code to use it?
For SQL, data copy and backup, no: you build it on screen. A script (Python, Shell or PowerShell) is only needed when the routine has to talk to something that is not a database — an API, a remote file, a legacy system.
Does it integrate with systems that have an API, such as Salesforce, Dynamics or our own ERP?
It does, through the Python step: any system with a REST or SOAP API is within reach, and credentials arrive as environment variables. There is no catalogue of ready-made connectors to drag in — in exchange, no integration is out of reach and there is no extra module to buy.
Does it work without internet access, inside our network?
It does. It is installed on your server, in a container, and with the control database on your premises too nothing needs to leave the network. There is no telemetry and the product does not “phone home”.
Does it replace cron and SQL Server Agent?
It does, and it solves what they do not: a single routine crossing databases from different vendors, with history, an alert when it fails, control over who may run it, and a version of whatever was changed.
Does it run on Windows?
The portal and the executors run today on Linux, in a container — including on Windows Server with virtualisation. The native Windows executor is under development and is not yet available for purchase.
How do I find out that a routine failed?
By email, at two independent levels — the whole process and each individual step — and on the dashboard, which shows what ran, when, for how long and with what result, together with the full execution log.

Shall we run one of your processes?

We will build, together with you, a routine much like the one running in your company today.

Talk to a specialist