---
title: 'Versions and compatibility'
description: 'Choose a matching server and SDK, and use an installation source that contains the required packages.'
category: 'Reference'
---

These guides follow the coordinated **0.5.0** source release. Server and SDKs are released independently. A version written in source does not by itself mean an image or package is available in a public registry.

## Supported starting point

| Component        | Source version | Runtime                               |
| ---------------- | -------------- | ------------------------------------- |
| Pipelogiq server | 0.5.0          | Docker is the recommended local setup |
| .NET SDK         | 0.5.0          | .NET 8 or later                       |
| Java SDK         | 0.5.0          | Java 17 or later                      |

Use the matching server and its database migrations for the reliability, approval, append, worker-session, and scheduling contracts shown here. Older preview installation instructions are not interchangeable with these guides.

## Package sources

The getting-started guides contain a complete source-build installation path. It lets you use the current SDK without assuming a package has reached a public feed.

- [.NET](/docs/net/getting-started): pack the SDK and restore from a local package feed. The legacy PipelogiqSDK preview package is not a substitute for the split 0.5.0 modules.
- [Java](/docs/java/getting-started): install the Maven modules from source, then build the example against those local artifacts. Maven group IDs use `com.pipelogiq`; Java imports use `io.pipelogiq.sdk`.
- [Server](/docs/installation): build with the supplied Compose configuration, or verify all pinned registry images before choosing the registry path.

When public artifacts become available, use the exact version and coordinates in the corresponding SDK guide. Do not mix preview dependencies into a 0.5.0 example to satisfy a failed restore.

For a new Java worker or producer, use `com.pipelogiq:pipelogiq-sdk:0.5.0`. It includes configuration, the typed client and both transports. Spring Boot, agent, store, testing and telemetry integrations are optional modules. The matching source archive and downloadable applications use this API; older examples that manually create runners still use a supported lower-level interface.

The current Java facade was exercised on JDK 17 and 21 against the local API, RabbitMQ, Redis and PostgreSQL. Java 17 bytecode is generated. A newer JDK may run it, but the recorded verification does not establish a test matrix beyond those two versions. See [Java testing](/docs/java/testing) for application-level checks and the limits of deterministic fixtures.

## Check a running server

```bash
curl -fsS http://localhost:8081/version
```

This returns the running server's version information. Also verify which image or source revision was deployed and whether its migrations completed. A healthy port alone does not establish protocol compatibility.

## Upgrade in a controlled order

Back up the database and integration encryption key. Read the changes for the target version. Upgrade the server with its migrations first, then application workers and producers using the compatible SDK.

Run a small pipeline, a transient retry, and the workflows that use approvals, schedules, or appended stages before moving regular traffic. Use [deployment guidance](/docs/deployment) and the SDK reference for package-specific requirements.