Neraya AI — AI Project Workspace

Context & Overview

Neraya AI is a private, account-based AI workspace I am building on my own. The premise is that a chat session is a bad container for work: you ask something useful, the answer scrolls away, and a week later you are re-explaining the same context to get back to where you were. Neraya treats a conversation as the input to something durable instead — a project that owns its messages, references, files, and artifacts, and keeps them across sessions.

The project is in active development. It has a working application shell, database schema, authentication, and model registry, but it is not publicly released, so nothing here is presented as a live product.

My Role & Responsibilities

I am the only developer on it, which means every layer is mine to defend:

• Own the product definition, data model, and API contract before writing feature code.
• Build the Next.js application shell: routing, layouts, theming, and the i18n layer.
• Design the PostgreSQL schema and its Drizzle migrations, including deletion behaviour.
• Implement authentication: credential hashing, session issuance, revocation, and route protection.
• Write the server-side model adapter that talks to the router and re-emits provider output as a stream.
• Maintain the test suite and the documentation set that describes the system.

The Problem & Operational Challenges

• Context evaporates. A chat transcript is linear and ephemeral. It has no notion of "the thing we are working on," so context has to be rebuilt by hand every session.
• Output gets lost in scroll. Useful results arrive as messages and stay there. There is no versioning, no comparison, and no way to export the good one.
• Provider credentials are a liability. The convenient design — let the browser call the model provider directly — puts an API key in reach of anyone with devtools. That is not something I am willing to ship.
• Models change faster than the frontend. Hard-coding model IDs and endpoints means a code change every time a provider ships something new.

Architectural Approach & Engineering Decisions

1. One TypeScript modular monolith. Next.js 15 App Router on the Node runtime, with clear layers rather than services split prematurely. Types flow from the database schema outward.
2. Server-side authority for model traffic. The browser only ever talks to the Neraya API. The server holds the router configuration, maps a public model ID to a router target, and streams the response back over SSE. No provider credential and no upstream endpoint is ever sent to the client.
3. Models as data, not code. The model registry lives in configuration and the database, so a new model is an operational change rather than a frontend release. An empty registry renders an honest "unavailable" state instead of inventing entries.
4. PostgreSQL with Drizzle migrations. Reviewed SQL migrations under version control, with a schema built around projects owning their own conversations, artifacts, and settings, and explicit deletion behaviour for each relation.
5. Self-hosted sessions, no JWT. Credentials are hashed with Argon2id. Sessions are server-side rows referenced by an HTTP-only cookie, so revocation is a delete rather than a wait for a token to expire.
6. Validation at every boundary. Request bodies, query parameters, environment configuration, and the router's responses are all parsed with zod. A configuration mistake fails at startup with a clear message, not at runtime with a mystery.
7. Documentation as part of the build. The system is described by a set of specification documents that are checked in and verified by a script, so the description cannot silently drift from the code.

Measurable Outcomes & Limitations

• Honest status: in development, not released. There are no production metrics to report, and I am not going to invent any.
• What exists today: the application shell runs, configuration is validated at startup, the schema and migrations are in place, authentication and the model registry are implemented, and lint, typecheck, tests, and build run in CI.
• What does not exist yet: the full chat experience, conversation search and organisation, message editing and response versioning, and file attachments. These are tracked in the repository roadmap rather than implied by this page.
• Honest Limitations: the repository is private and there is no public URL yet, so there is nothing here to click. It also depends on a configured router and a database — with an empty registry it correctly refuses to generate rather than degrading into a fake response. A walkthrough is available on request.

Technologies Used

• Framework: Next.js 15 (App Router, Node runtime), React 19, TypeScript
• Styling: Tailwind CSS 4 with a semantic token layer
• Data: PostgreSQL, Drizzle ORM and versioned SQL migrations
• Auth: own session layer, Argon2id credential hashing, HTTP-only cookies, OAuth-ready
• AI Integration: server-side adapter to a self-hosted OpenAI-compatible router, SSE streaming
• Validation & Quality: zod at every boundary, Vitest, ESLint, Prettier, CI