SDKs

More

Lockwell ships first-party native-wire SDKs for Go, Node, and Java 25, plus source-shipped LNW/1 integrations for server-side TypeScript (Node/Bun), SolidStart v2, Next.js 16.3+, Nuxt 4.5+, and Spring Boot 4.1/JDK 25. Every SDK retains explicit S3, Admin, or HTTP/JSON compatibility surfaces where documented, and every transport enters the same encrypted, multi-tenant domain pipeline rather than creating a second store.

Release boundary

The current public snippets describe source and historical private package coordinates. v0.2.2 predates the selected PolyForm distribution payload and is not a current approved TangibleShift or commercial release; publication and commercial use remain behind B-010/B-013 and a written grant.

You build your object-storage layer on one explicitly selected transport. There is no second store and no implicit transport switching.

Native Wire transport

LNW/1 is a deterministic binary transport for the native data plane. It is experimental, opt-in, and disabled by default. The existing HTTP-native JSON client remains the supported default until a deployment completes the LNW qualification gates. The Native Wire guide covers TLS 1.3/mTLS, capability negotiation, streaming, retry and failure semantics, and rollback.

The currently merged LNW consumers are:

Integration	Runtime contract	Guide
@kelphect/sdk-native 0.1.0	Node 22+, Bun 1.4+; server-only	Node/Bun guide
github.com/RusticStack/lockwell-sdk-go/lockwellwire	Go 1.27+; server-only	Go SDK
com.lockwell:lockwell-spring-boot-starter 0.2.2	JDK 25, Spring Boot 4.1.1; separate --release 25 artifact	Spring guide

These package coordinates are source/test contracts and may still be behind the approved publication gate. The standalone Go LNW client ships in the Go SDK module (lockwellwire); the Java 25 shared-core LNW client ships inside com.lockwell:lockwell-sdk. The capability index withholds the production-ready claim until the combined exact-head Oracle, cluster, benchmark, CI, and security gates pass.

The three surfaces

Surface	Talks to	Auth	Use it for
S3 client	the S3 listener (SigV4 + XML)	SigV4 on every request	A drop-in for AWS S3 clients, including query-SigV4 object presigning for GET, PUT, HEAD, and DELETE.
Native wire client (Go)	the LNW/1 binary data plane on native_wire.listen_addr	TLS 1.3 plus per-handshake HMAC proof	Typed binary streaming, ranges, multipart, versions, Object Lock, CORS, notifications, and signed capabilities.
Legacy native client	the native JSON data plane, /api/v1/ on the public listener	a short-lived bearer token (lwtk_…) minted from an access key, auto-managed	Explicit HTTP/JSON compatibility for existing deployments.
Admin client	the JSON Admin API, /admin/api/v1/ on the admin listener	an admin API bearer token (lwadm_…)	Provisioning tenants, accounts, scoped keys, quotas, audit.

On top of those, the app kit (LockwellKit) composes the admin and native clients into the five jobs a multi-tenant app would otherwise hand-roll:

• Provision a tenant plus a scoped key.
• Get a per-tenant data client.
• Configure browser CORS for signed URL fetches.
• Mint browser-direct signed upload and download URLs.
• Verify webhooks.

Which one do I use?

• Moving objects from an existing S3 codebase? Use the S3 client. It signs byte-for-byte like AWS and exposes query-SigV4 object presigners for GET, PUT, HEAD, and DELETE. All four helpers have implementation and offline method-binding coverage; the tracked Phase 2 quick matrix records separate passing live GET, PUT, HEAD, and DELETE rows for Go, Node, and Java. The quick profile deliberately excludes the 10/15 GiB scenarios.
• Building a new server application? Use the language's LNW/1 client: lockwellwire.Client, Node's package-root NativeClient, or Java's LockwellNativeWireClient. Each uses TLS 1.3 and never falls back. Existing HTTP/JSON deployments use the explicitly named compatibility clients. Browser/edge code must use the separate @kelphect/sdk/edge JSON-safe entry; native-wire packages deny browser imports.
• Provisioning tenants and keys? Use the admin client against the admin listener, never the public S3 port.
• Building the whole multi-tenant integration? Use the app kit. It provisions tenants, hands you per-tenant clients, and mints browser signed URLs.

See The three surfaces for the conceptual tour. For transport/TLS/timeouts and the exact cross-language differences, read Client configuration and the machine-checkable capability index. Existing S3 applications should also read Migration and compatibility.

Need browser-direct uploads? The S3 client can presign PUT, while the native client can mint a method- and

scope-bound signed PUT URL without SigV4. Choose the surface that matches the application's integration model. :::

Small, explicit dependency boundaries

The core SDKs keep their platform dependencies narrow and make framework dependencies explicit.

• Go uses the standard library only (net/http, crypto/*, encoding/*).
• Node's S3 and JSON compatibility surfaces use platform APIs. The server-only native client has the explicit @kelphect/sdk-native peer; the dedicated edge entry excludes it and remains node:*-free. See Edge runtimes.
• Java's SDK uses the JDK plus optional Micrometer/OpenTelemetry integration. The Spring Boot starter declares its Boot 4.1 dependencies and delegates the wire implementation to the core Java 25 SDK.

The Go, Node, and Java S3 clients share a language-neutral set of SigV4 signing fixtures, so all three sign byte-for-byte identically.

All three clients also preserve a clean reverse-proxy endpoint prefix in normal requests, native/admin routes, SigV4 canonical paths, and presigned URLs. An endpoint that already includes /api/v1 or /admin/api/v1 is normalized once; traversal and encoded-separator paths fail closed. See the language pages for transport timeout and cancellation options. This is deterministic SDK evidence; it does not claim hosted or multi-node deployment proof.

Leaner than the AWS SDK

Lockwell's clients spend less client CPU per request than the AWS S3 SDK in the same language. The native (bearer + JSON) client is the leanest of all: it mints its bearer token once and reuses it, skipping per-request SigV4 canonicalization and HMAC key derivation.

The numbers from the client-overhead micro-benchmarks:

• The Go S3 client allocates roughly 30-40% fewer objects per PUT/GET than aws-sdk-go-v2.
• The Node and Java native clients beat @aws-sdk/client-s3 and software.amazon.awssdk:s3 on every measured operation in the cited client-overhead microbenchmark.
• The widest margin is on list responses, where the AWS SDK's XML deserializer is the expensive part.

These measure client overhead only, not end-to-end storage or provider-replacement performance. The full methodology, including the loopback/mock setup and Java HTTP-client caveat, lives in the SDK benchmarks.

Language references

• Go SDK covers lockwellsdk (lockwell-sdk-go), lockwellwire (lockwell-sdk-go), legacy lockwellnative (lockwell-sdk-go), lockwelladmin (lockwell-sdk-go), and lockwellkit (lockwell-sdk-go).
• Node SDK covers @kelphect/sdk and @kelphect/sdk/edge.
• Java SDK covers com.lockwell:lockwell-sdk and the Spring Boot starter.
• Java native client covers HTTP-native JSON retry, timeout, and idempotency settings for JVM services.
• Native Wire guide explains the transport and its exact limits.
• Spring Boot Native Wire covers the JDK 25 starter and TangibleShift-shaped server pattern.
• Native TypeScript covers the shared LNW/1 server transport for Node and Bun.

Reference pages

• S3 operations reference is the full operation matrix shared by all three S3 clients.
• Native data-plane API is the JSON /api/v1/ wire contract.
• Native Wire protocol is the binary LNW/1 envelope, registry, and error reference.
• Admin API is the JSON /admin/api/v1/ wire contract.
• SDK capability index maps shipped capabilities across all three languages and links to /sdk-capabilities.json and /sdk-public-api-examples-v1.json for tools and AI agents.