The standard shape of a data platform is to move first and think second. Collect everything, ship it to a central system, and work out there what any of it means. That order made sense when storage was the cheap part and the volumes were small enough that moving them was incidental.
Neither condition holds now. Sensor fleets, vehicle telemetry, and application logs generate more than most organizations can afford to centralise, and the bill arrives from three directions at once: egress, ingest, and retention. The uncomfortable part is that a large fraction of what gets moved is never queried. It is moved because moving it was the default.
Deciding what to send requires knowing what the data contains, which is the thing you cannot do from the far side of the transfer. So it is worth being able to run a transformation where the data is produced, look at the result, and choose.
What local processing actually means
Local processing means the transformation runs on the machine, or within the environment, where you put it. With Expanso Edge in local mode you can submit a pipeline and inspect its output without connecting to a cloud orchestrator at all.
That matters most when your first question is about the transformation rather than the infrastructure. Can you select the fields you need? Does the filter catch the condition you care about? Does the output match the shape the next system expects? Those are answerable in a couple of minutes on a laptop, and none of them require credentials, a broker, or a destination.
It is worth being precise about the boundary, because “local” is doing less work in that sentence than people assume. A locally running process can still make network calls if its inputs or outputs are configured to do so. Local mode describes where the orchestration decision is made, not a guarantee that nothing leaves the host. Read the full configuration before treating a pipeline as self-contained, and treat credentials, error paths, and whatever else runs on that machine as part of the deployment review.
Start with synthetic data and one visible result
The temptation when trying a new tool is to point it at something real immediately. Resist it for the first run.
A small synthetic fixture lets you predict the output before you see it, which is the only way to tell whether the pipeline did what you meant or something that merely looks plausible. Introducing credentials, a live source, and a remote destination at the same time as an unfamiliar transformation means that when something fails, you have four candidates and no way to separate them.
Here is the shape of a first run worth doing. A generated sensor reading arrives with a device identifier, a temperature, and a raw payload. The pipeline checks the temperature against a threshold, adds an alert flag, and forwards a record containing the identifier, the reading, and the flag, while leaving the bulky raw payload out. The output is one line of JSON you can read in the terminal that started the service.
That is a complete, verifiable result. It also happens to be the core pattern behind most edge data work: evaluate a condition at the source, forward the conclusion, and leave the volume behind.
Starting the service and submitting a job are different steps
One practical note that trips people up. Running the local node and submitting a pipeline to it are separate actions in separate terminals, and a command being accepted is not the same as the pipeline having worked.
Keep the service terminal visible. Submit the job from the second terminal. Then read the output in the first. The submission returning cleanly tells you the configuration parsed and the node accepted it; the records printing tells you it ran. Confusing the two is the most common reason someone concludes a pipeline works when it has not yet produced anything.
We published this as a runnable example with the configuration, the synthetic input, and the exact expected output. It links out to the installation steps and takes a few minutes end to end.
What the first run does not prove
It is worth stating plainly what a successful local run establishes, because the gap between that and a production deployment is where optimism does the most damage.
You have demonstrated that a transformation produces a known output from a known input on one machine. You have not demonstrated that a fleet buffers through a network partition, that every record is delivered after reconnection, that the pipeline survives a restart mid-batch, or that the destination received what you think it received. Each of those is a separate test against the storage, destinations, and failure conditions you actually intend to use, and each has caught real problems for real teams.
Delivery guarantees in particular deserve their own investigation rather than an assumption. Anyone who has operated a distributed system recognizes the gap between “the sender reported success” and “the record exists at the other end”, and the Jepsen analyses are a long catalogue of systems where that gap turned out to be wider than documented.
Moving from the fixture to your own data
Change one thing at a time, in roughly this order.
Adapt the transformation to synthetic records shaped like yours, so you are testing your logic against a schema you control. Then swap in a small approved sample of real data, which is where you discover the fields nobody documented and the values nobody expected. Only then add the intended destination, and verify receipt at that destination rather than inferring it from the sender.
When you need central deployment, scheduling, and fleet visibility, that is the point to bring in the orchestrator. Carry the same input-and-expected-output checks forward, because they are what tell you whether deploying it changed the behavior you already verified. Our product page covers how the control plane and the compute agents divide responsibility, and the pricing page sets out the free tier and the scoped pilot programmes if you want to run this on a real workload.
A modest first milestone is the right one
You supplied known records, a pipeline processed them where they were produced, and you can explain the result. That is a small thing to have achieved and a solid basis for the decision that follows, which is what should happen to this data before it reaches anything else.
Run the local processing example and start from an output you can read.
