Inside Lioran S3
The most important architecture choice in Lioran S3 / Lioran Bastion is not the HTTP framework.
It is the separation between metadata and object payload data.
Lioran S3 V1 Pre-Alpha launched on October 1, 2026. The project is built by Lioran Developer Solutions under Lioran Group, led by Swaraj Puppalwar.
Two planes
Conceptually:
HTTP API
|
+---------+---------+
| |
v v
Metadata Plane Object Data Plane
RocksDB Filesystem
| |
bucket records object bytes
object metadata staged uploads
multipart state committed blobs
media state range reads
The core rule is:
Object payload bytes do not belong inside the metadata database.
RocksDB stores records about objects.
The filesystem stores the actual object bytes.
Why separate them?
An object store has two very different workloads.
Metadata wants:
- indexed lookup
- compact records
- atomic state transitions
- prefix/list support
- bucket configuration
- multipart manifests
- user/security records
- media job state
Object payload I/O wants:
- sequential streaming
- bounded buffers
- range reads
- direct filesystem access
- large files
- durable promotion from temporary state
Trying to make one subsystem behave like both usually produces an awkward compromise.
Bounded-memory streaming
A 100 GB object should not imply 100 GB of heap.
The object engine works with fixed-size chunks.
Conceptually:
network socket
|
v
bounded buffer
|
v
file descriptor
Download reverses the direction.
This keeps memory tied more closely to active concurrency and chunk size than to total object size.
Atomic write lifecycle
A safe object write should not become visible halfway through receiving bytes.
The architecture follows a staging model.
Conceptually:
incoming stream
↓
temporary object
↓
checksum / flush
↓
metadata commit
↓
promotion
↓
visible committed object
A partially uploaded object remains separate from a committed object.
That distinction is one of the core storage invariants.
User keys are not filesystem paths
Suppose a user writes:
../../something-dangerous
An object store must never blindly concatenate user input onto a storage root and hope path normalization saves the day.
Lioran S3 treats user-controlled keys as logical identifiers and internally maps storage placement.
RocksDB
RocksDB is embedded into the storage process for metadata persistence.
The metadata layer is responsible for information such as:
- bucket records
- object metadata
- object indexes
- prefix listing state
- multipart uploads
- video/media state
- quotas
The payload itself remains outside RocksDB.
HTTP layer
The Rust server uses Axum/Hyper-style HTTP infrastructure and exposes native REST APIs.
V1 uses its own REST protocol and Bastion URI scheme.
AWS S3 API compatibility is future scope.
That distinction matters because “S3-style object storage” and “AWS S3 protocol-compatible” are not the same statement.
Why not distributed yet?
The project intentionally defers:
- Raft/Paxos-style consensus
- replication topologies
- erasure coding
- cluster membership
- active-active nodes
A distributed system multiplies local failure modes.
If local object commit semantics are wrong, replication merely creates several copies of the wrong behavior.
V1 therefore puts single-node correctness first.
Critical invariants
Several rules define the design philosophy:
- never load whole large objects into memory
- object bytes and metadata stay separate
- do not acknowledge a durable write too early
- every mutation needs a crash state
- incomplete objects cannot appear committed
- metadata should not intentionally point to nonexistent committed data
- external paths must be validated or internally mapped
- correctness outranks benchmark screenshots
- performance optimization must be measured
- distributed storage comes after a proven local engine
Why Rust?
Storage software benefits from:
- explicit ownership
- predictable data lifetimes
- strong concurrency tooling
- low-level filesystem control
- high throughput without a garbage-collected runtime on the data path
Rust does not magically make storage correct.
It gives the implementation a useful set of constraints while still allowing direct systems programming.
The correctness model still has to be designed.
Where TypeScript fits
Rust owns the server.
TypeScript owns the primary developer-facing SDK and CLI ecosystem.
That gives application developers a familiar interface:
const bucket =
client.bucket("media");
await bucket.put(
"hello.txt",
"hello"
);
while the storage path remains implemented in Rust.
The larger goal
Lioran S3 is one component of the infrastructure stack being developed by Lioran Developer Solutions and Lioran Group.
The project is still pre-alpha, but the architecture is being documented publicly so developers and automated tools can understand not just the commands, but the reasoning beneath them.
Top comments (0)