---
title: "Quickstart"
description: "Run a workflow locally, see every step, and give your team a useful answer."
category: "Get started"
---

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](/docs/installation). 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](/docs/compatibility).

## 2. Choose your SDK

| Your application | Start here | What you will run |
| --- | --- | --- |
| .NET 8 or later | [.NET getting started](/docs/net/getting-started) | A typed HTTP handler, a worker, and a pipeline submission |
| Java 17 or later | [Java getting started](/docs/java/getting-started) | A complete Maven project with an HTTP worker and typed handlers |
| Another runtime | [HTTP worker protocol](/docs/http-workers) | 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](/docs/troubleshooting) 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](/docs/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](/docs/use-cases) to choose a starting point, or copy an [AI integration prompt](/docs/ai-prompts) into your coding assistant with the project open.

Before moving to a shared environment, follow [access management](/docs/access), [reliable execution](/docs/reliability), and [deployment](/docs/deployment).