pipelogiqQuickstart
Run a workflow locally, see every step, and give your team a useful answer.
Pipelogiq coordinates your workflow. Your workers execute the business logic. The dashboard gives your team a shared record of what happened.
Start with a local server and one small worker. You do not need to connect a real payment provider, CRM, or AI account to complete this walkthrough.
1. Start Pipelogiq
Follow Install Pipelogiq with Docker. It includes the complete configuration, first administrator sign-in, an application API key, and a smoke test that runs a pipeline with a retry.
The local dashboard is at http://localhost:3300. Application workers connect to http://localhost:8081. These are different endpoints: use the external API address in SDK configuration.
Already have a server? Ask its administrator for the external API URL and a key for the application you will use. Confirm the server and SDK combination in Compatibility.
2. Choose your SDK
| Your application | Start here | What you will run |
|---|---|---|
| .NET 8 or later | .NET getting started | A typed HTTP handler, a worker, and a pipeline submission |
| Java 17 or later | Java getting started | A complete Maven project with an HTTP worker and typed handlers |
| Another runtime | HTTP worker protocol | The wire contract for your own worker implementation |
The .NET and Java guides contain all source files and configuration. Start with the HTTP transport; it connects the application worker through the API. AMQP is available when you want direct broker connectivity from that worker.
HTTP does not remove RabbitMQ from the Pipelogiq server stack.
3. Follow the run
After submitting the example, keep its pipeline ID. Open Pipelines in the dashboard and find the run using its name or context. Select it to inspect:
- Stages: each registered handler and its execution status.
- Logs: messages emitted during the operation.
- Context: the identifiers and values the workflow shares.
- All data: technical input, output, and execution metadata.
A successful tutorial ends with a Completed pipeline. Seeing a worker start is only an intermediate step; the completed run confirms that the server and application worker are communicating.
If it remains Pending, check the API URL, application key, worker readiness, and exact handler names. The troubleshooting guide explains the next checks.
4. Make a failure understandable
The installation smoke test deliberately reports one transient failure before succeeding. Open the first stage and inspect its attempts. This is the same pattern used when a CRM is temporarily unavailable.
For your own first integration, expose a useful reference such as orderId, a readable stage name such as Sync customer profile, and an explicit result. A successful payment followed by a failed CRM update should remain two distinct steps, so support can see which operation completed.
Learn the pattern in Payment reconciliation. The guide explains where to place retries and how to avoid repeating an external side effect.
5. Bring one existing workflow
Pick a process your support team already asks engineers about. Keep existing business functions and call them from handlers. Start with a small number of meaningful stages.
Use use cases to choose a starting point, or copy an AI integration prompt into your coding assistant with the project open.
Before moving to a shared environment, follow access management, reliable execution, and deployment.