OSDU-Lite runs the OSDU service APIs locally in a single in-memory process

What OSDU-Lite is

A developer has published OSDU-Lite, an open-source emulator that reproduces the HTTP surface of the Open Subsurface Data Universe (OSDU) platform inside a single in-memory process. According to the project's announcement on dev.to, the entire implementation lives in one Python file, server/server.py, and a client written against a real deployment can simply be pointed at localhost:8089 instead, unchanged. The pitch is explicitly modeled on LocalStack, the widely used AWS emulator: no cloud, no OpenSearch, no OIDC provider, no persistence layer.

OSDU is a set of standard service contracts for the energy industry — Storage, Search, Dataset, File, Workflow, Legal, Schema and Entitlements — that underpins production subsurface data platforms. A real deployment, however, assumes Kubernetes plus OpenSearch, Redis, PostgreSQL and an OIDC provider. The author's framing is that this is a fair ask for a platform team, but a disproportionate amount of machinery for answering the narrower question of whether a client actually works.

Setup is a single docker run against a multi-arch image (amd64 and arm64) published on GitHub's container registry as sohaibqasem/osdu-lite; building from source is make start, with make smoke checking health, entitlements, legal tags, kinds and search. Restarting the process resets the platform to a clean state, which suits the three use cases the author targets: local development, tutorial walkthroughs and CI.

What is emulated

The emulator covers the core services at the API versions real clients use:

• Storage v2: PUT/GET/PATCH/DELETE, version history, copy, batch operations, kinds and cursors
• Search v2: Lucene-style queries, cursor queries, aggregations, as-owner and health
• Dataset v1: registration, storage and retrieval instructions, registry, revoke and soft delete
• File v2: metadata, upload URLs, signed delivery and getLocation
• Workflow v1: deploy/list/run lifecycle plus Osdu_ingest manifest ingestion
• Legal v1: legal tag CRUD, validation, batch retrieval, properties and query operators
• Schema v1: kind listing and schema create/update/system
• Entitlements v1 and v2: groups, members, membersCount, roles and appIds

Deliberate fidelity choices

Two behaviors matter for anyone writing real code against the emulator, per the dev.to post. First, ingest is validated the way a deployment would validate it: a record needs a known kind, acl.viewers and acl.owners, and legal tags that actually exist in the Legal service. Failures return a 400 with a reason, so clients cannot quietly ship malformed records.

Second, Storage and Search are asynchronous by design. A record is stored immediately but only becomes searchable after a simulated indexer delay, 0.7 seconds by default — reproducing the familiar experience on a real OSDU of ingesting a record and not immediately finding it in search.

Dataset retrieval instructions also carry integrity data, including size and SHA-256 for every known file, and the bundled demo client aborts if a downloaded LAS file fails the checksum.

The Well 360 reference example

Rather than shipping bare API stubs, the repository includes a complete Well 360 integration that follows the shape of the official OSDU tutorial chain: Well to Wellbore to WellLog to Dataset to LAS. Three demo scripts progress from record-by-record ingest with a LAS upload, to a bulk load of 3 wells, 4 wellbores, 4 well logs and 4 datasets, to manifest ingestion via Osdu_ingest.

The centerpiece is a Java consumer, Well360App, compiled against the genuine org.opengroup.osdu:os-core-common SDK. It searches well EAGLE-01, reads record W-1001, resolves its wellbores and well logs, fetches dataset retrieval instructions, downloads and checksums the LAS file, then runs a cursor search. It writes no state, which the author positions as a safe read-only probe of the full chain.

Tests and CI

The project carries 73 tests in zero-dependency stdlib unittest — no Docker or live server required — covering record validation and version history, delete and purge, the search query language and cursor lifecycle, the indexer delay, dataset integrity, File v2, manifest ingestion, LegalTag operators, Schema, entitlements RBAC and TTL cleanup.

CI is deliberately offline and deterministic: the unit suite, a live smoke test, and a client contract check that pins the os-core-common API surface the demo consumes. No CI step depends on an external package registry.

Moving to a real OSDU

Defaults — base URL, partition, bearer token, ACL groups and approved legal tags — are all overridable, and the Java Search and Storage code is said to work unchanged against a real deployment, aside from confirming routes and schema versions before ingesting. Production concerns such as OIDC, TLS, retries and metrics are intentionally out of scope for an emulator.

Why it matters

OSDU's value lies in its contracts, but until now testing against those contracts meant either provisioning a full cloud and Kubernetes stack or hand-rolled mocks that can drift from the real APIs. Emulators have already proven this pattern works elsewhere — LocalStack for AWS — and it now extends to the energy industry's data platform standard. The details matter: strict ingest validation and a simulated indexer delay mean code exercised against the emulator is more likely to behave identically on a real OSDU, and the Java demo compiled against the official SDK, with its API surface pinned in CI, turns compatibility from a claim into something checked automatically. For tutorial authors, integration developers and anyone preparing a demo, the cost of a first OSDU run drops from setting up a cloud account to a single container command.