SDKs

Lockwell ships first-party SDKs for Go, Node, and Java. Each language exposes three client surfaces plus a high-level app kit over the same encrypted, multi-tenant store.

You build your whole object-storage layer on one dependency. There is no second store and no custom glue.

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. Presigned GET only.
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	JSON in, JSON out. Signed GET and PUT URLs, bucket notifications, edge runtimes.
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 four jobs a multi-tenant app would otherwise hand-roll:

• Provision a tenant plus a scoped key.
• Get a per-tenant data client.
• 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, so it drops in. The one deliberate difference: presigning is GET-only (no presigned writes; use the native signed PUT URL instead).
• Building a new app, or running on an edge runtime? Use the native client. It is JSON-native (no SigV4, no XML), auto-manages its bearer token, and mints signed write URLs for browser-direct uploads. In Node it is edge-safe.
• 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.

Need browser-direct uploads? The S3 client presigns GET only. Mint a signed PUT URL from the native client

instead. :::

Zero runtime dependencies

Every SDK is built on its platform's standard library. There is no third-party dependency tree to audit or update.

• Go uses the standard library only (net/http, crypto/*, encoding/*).
• Node uses the global fetch, crypto, and ReadableStream (Node >= 20). The native client and app kit import nothing from node:* and run unchanged on edge runtimes; see Edge runtimes.
• Java uses the JDK only (java.net.http, javax.crypto, java.security, java.util.zip). The Spring Boot starter pulls Spring in only when it is present.

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

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 operation.
• 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. The full methodology and tables live in the SDK benchmarks.

Language references

• Go SDK covers pkg/lockwellsdk, pkg/lockwellnative, pkg/lockwelladmin, and pkg/lockwellkit.
• Node SDK covers @kelphect/sdk and @kelphect/sdk/edge.
• Java SDK covers com.lockwell:lockwell-sdk and the Spring Boot starter.

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.
• Admin API is the JSON /admin/api/v1/ wire contract.