-
-
Vault
Inspiration
Every time we start a new project, we find ourselves copy-pasting the same boilerplate for inter-service authentication. Credentials pile up across .env files, secrets drift out of sync, and onboarding a new service means hunting down which tokens go where. We wanted to solve this once — a single registry that owns the trust layer between services so we never have to think about it again.
What it does
Ascenvo is a service-to-service communication registry. Multi-tenant services register themselves on the platform and expose controlled access. Single-tenant services consume that registry through a simple config — no manual credential exchange, no .env sprawl. From the moment a service registers, it can authenticate with any permitted peer in one click, with Ascenvo handling the credential lifecycle end-to-end.
How we built it
We took an iteration-first approach: identify the smallest concrete problem blocking us, solve it, then surface the next one. This kept the architecture honest — each layer exists because a real constraint demanded it, not because we planned it upfront. The core is a vault structure that stores service identities and their trust relationships, paired with a registration flow that wires authentication automatically on enrollment.
Challenges we ran into
The hardest design question was boundary definition: which service belongs to which entity, and how do you represent that in a schema with zero ambiguity? Getting multi-tenancy right meant drawing strict lines — where the multi-tenant platform owns responsibility versus where a single-tenant consumer operates — and deciding which APIs live at the platform level rather than being pushed down into each tenant's own logic. Keeping those boundaries clean in the database, with no risk of cross-tenant data leakage, was the core architectural puzzle.
Accomplishments that we're proud of
We shipped a working vault structure where any service can register, discover peers, and complete mutual authentication without a single env variable ever being manually managed. The entire onboarding flow — registration, trust establishment, credential issuance — happens in one step. That was the north star from day one, and we hit it.
What we learned
Separation of concerns isn't just a code quality principle — it's a security boundary. The discipline of deciding exactly where the multi-tenant platform ends and a single-tenant consumer begins forced us to be explicit about trust in ways that made the system safer as a side effect.
What's next for Ascenvo
We're planning to package the core registry and authentication flow as a public SDK. Right now Ascenvo works as an admin-managed platform; the next step is exposing the same primitives as a drop-in bundle so any developer can bring the same zero-env service communication pattern to their own stack.
Log in or sign up for Devpost to join the conversation.