Case study / Product & infrastructure
LWDGY
ASTERI.
A jewelry storefront with the infrastructure and release checks needed to support it.
The project connects a customer-facing store, a separate management workspace and a controlled deployment process. This case study follows the path from application features to a checked, signed release.
01 / The problem
Build the store.
Support the operation.
The storefront needs to help a customer find products, explore combinations and manage a cart or account. The maker needs a separate place to manage products, inventory and orders.
Those interfaces also depend on identity, permissions, protected checkout operations and a deployment that can be checked. The project brings those parts together while keeping customer and administrative responsibilities clear.
These are product goals supported by the implementation. Customer research, sales growth and conversion impact were not measured in this case study.
02 / The system
Three connected layers.
Interfaces, services and delivery each have a clear job.
Customer & management
React and TypeScript interfaces provide the storefront and a separate dashboard. Vite builds the browser applications.
Catalog · Product pages · Cart · ManagementIdentity & application data
Firebase Authentication and Firestore support identity and data. Express handles protected operations, including authoritative checkout work.
Identity · Permissions · Data · Protected APIsContainers & routing
Docker packages the application, dashboard and proxy services. Traefik routes HTTPS traffic to the appropriate application surface.
Image · Runtime configuration · DNS · TLSCatalog components can subscribe to Firestore directly. Sensitive server operations verify identity and permissions; the diagram does not imply that every data read passes through Express.
03 / Engineering decisions
Make the boundaries
visible and testable.
Package a known runtime.
Multi-stage Docker builds separate building from running. The runtime uses a non-root user, read-only filesystems and bounded resources. Runtime secrets remain outside the built image.
Tradeoff: a shared tested image simplifies release identity across services, while increasing what that image contains.
Configure the proxy explicitly.
Routing and HTTPS configuration identify which service handles customer and administrative traffic. Persistent certificate state supports container recreation.
Tradeoff: explicit configuration takes more maintenance, but avoids granting the proxy access to the Docker socket.
Verify sensitive actions on the server.
Protected APIs check identity and permissions. Checkout derives prices and stock from authoritative data and uses transactions for reservations.
Reason: browser input can request an action; it cannot decide the trusted price, inventory state or authorization outcome.
04 / The release challenge
Prove which version
reaches the server.
A successful build does not establish that the running service uses the same image or source revision. The delivery process needs an explicit link between the checked source, the tested image and the accepted deployment.
The standalone release gate runs the complete build/test workflow and produces signed evidence. Publication and deployment are separate steps.
- 01
Check committed source.
Run the application and policy checks against the intended source revision.
- 02
Build and inspect the image.
Build the production image, test its runtime behavior and scan the intended artifact.
- 03
Verify the published identity.
Publish the image and pull back its immutable digest to confirm the artifact being delivered.
- 04
Sign the passed checklist.
Bind the proof to the exact image, source revision and reviewed release policy.
- 05
Verify before deployment.
The server checks the proof before changing the release, followed by HTTPS revision checks.
05 / Checks & results
A documented acceptance test.
Recorded October 9, 2026
The cutover record documents both a rejected delivery and an accepted signed release. This provides a concrete check of the deployment boundary.
Negative case / Unsigned image
Rejected before
release-state change.
The actual server rejected the unsigned image before changing the deployed release state.
Positive case / Signed image
Accepted, then
checked over HTTPS.
The signed image was accepted. Storefront and dashboard revision checks matched the approved source.
These counts describe the October 9 record. The source records were reviewed for this case study; the release was not rerun for the page. New releases and hosts require their own verification.
06 / Contribution & assistance
Explain the work
and the help behind it.
I owned LWDGY ASTERI end to end: the design, development, server setup, Docker configuration, testing and release decisions.
AI assistance was part of the implementation, research and documentation workflow. I was responsible for the project direction, reviewing the work, testing and deciding what to release.
The source repositories are private. This page is a public-facing summary; credentials, customer data and private operational records are excluded.
Related work
Follow the RAG pipeline
in Newark Civic Pulse.
Official records, ETL, chunking and source-supported answers form a separate applied-AI case.