Zelyq

Vibecoding writes code. Zelyq builds like an engineer.

Try it live → zelyq.com

_{▶ Video Studio — create videos from a prompt or animate a starting image, then preview and download your results.}

_{▶ Image Studio — generate original images with prompts, reference images, and creative controls.}

_{▶ And checking the build at real mobile, tablet, and desktop widths right in the preview — no resizing the window.}

_{▶ And building a real mobile app — pick Expo — React Native when you create a project and the agent builds native screens (View / Text / Expo Router, not div), previewed in the browser via Expo web.}

Most "prompt to app" tools generate something that looks right and leave you to find out where it
isn't. Zelyq's agent plans before it acts, verifies its own work before it calls a turn finished,
tells you plainly what it checked versus what it assumed, and stops to ask instead of guessing when
a request is too vague to build responsibly. It writes files, runs commands, starts a dev server,
and reports back — while you watch every tool call, every file it touched, and the running result,
live.

Live demo · Why an engineer · Quickstart ·
How it works · Modes · Architecture ·
Configuration · Self-hosting ·
Roadmap · Contributing

It behaves like an engineer, not a generator

A code generator's job ends when something compiles. An engineer's job includes knowing what they
actually built, whether it works, and when they don't have enough information to keep going
responsibly. Zelyq's agent is built toward the second one:

• It verifies before it calls anything done. The moment the model stops asking for tools, Zelyq
  runs the project's own typecheck (or build) and checks the live preview for a crash — automatically,
  not because the prompt asked nicely. A turn that broke something gets handed back to fix, not
  reported as finished.
• It says what it knows versus what it guessed. Turn on Engineer Mode and every turn that
  changes something states its purpose up front, then separates what it verified (ran, read, tested)
  from what it inferred and what it assumed — instead of one confident-sounding paragraph that blurs
  the three together.
• It names the alternative it didn't pick. When a real choice existed — an architecture, a
  library, a tradeoff with no obviously-better answer — Engineer Mode has it say what it didn't choose
  and why, in a sentence or two, not silently.
• It plans before it builds, when the ask is big enough to need one. Architect Mode turns a
  vague request into a real design package first — requirements, decisions with the alternative named
  and why it lost, a data model and API, a DESIGN.md design system, a build plan broken into
  review-sized tasks — and waits for you to say "build it" before writing any code. Then it
  dispatches each task to a bounded builder, has a separate session verify the running app, and
  claims "done" only against a checklist it can show you. Turn on Auto Mode and it runs the
  passes itself, to a hard ceiling, instead of you typing "keep going".
• It has specialists. After a build verifies, named agents finish the job — each owns a spec
  file it surveys, writes, and implements, and each streams into the chat as a labelled sub-thread.
  The Designer (DESIGN.md — a coherent design system, no generic-AI look), the DevOps
  agent (OPERATIONS.md — CI, a Dockerfile, .env.example, deploy config), the Security/QA
  agent (QA.md — writes and runs the test suite, runs the security scan), and the Cinematic
  engineer (CINEMATIC.md — turns one screen into a scroll-driven film: a hero that scrubs your
  footage frame by frame as you scroll, a pinned reveal, a horizontal story, built to a
  senior-engineer skill). In Engineer Mode you call any of them yourself: "make it look
  professionally designed", "set up CI", "write tests", "make the hero play as I scroll".
  See docs/modes.md.
• A specialist can pause for something only you have. A cinematic hero is the footage, so the
  Cinematic engineer doesn't fake it against a placeholder: it writes a plain-language brief of
  exactly what to provide, creates the folder, and stops. You drop the file in and reply go — it
  validates what you gave it against the brief and takes it from there. A dispatched pass that asks,
  waits, and resumes from a plan it already wrote.
• It builds the backend, not just the screen. When a project needs saved data or accounts, the
  agent designs a Supabase Postgres schema with Row-Level-Security written per operation, applies the
  migration, wires the client, and has a separate session verify that a second user genuinely can't
  read the first user's rows. AI features too — a chatbot, an extractor, a classifier — with the
  provider key living in the backend, never shipped to the browser.
• It builds what was asked, then stops. No invented navbars, no sample-data toggles nobody
  requested, no filling a vague ask with guesses. A request too shapeless to build responsibly gets one
  clarifying question instead of eight files you didn't want.
• It reaches for expert practice only when a task needs it. A catalog of packaged, senior-level
  skills — frontend engineering, UI/UX design, application security, CI/CD — loads into a turn only
  when its description actually matches, so the agent isn't running a security review on a landing
  page or a deployment checklist on a button.
• It stops and asks instead of guessing on anything irreversible. Deleting data, an action with no
  undo, a request that's really a conversation ("I want to test you," "how would you build X") rather
  than a spec — Engineer Mode treats these as a reason to ask, not a reason to improvise.

None of this is a black box promise — every mechanism above is real code, not marketing copy: the
verification gate and Engineer Mode both live in apps/agent/src/session.ts
and apps/agent/src/prompt.ts, and docs/agent-behaviour.md
documents exactly how the turn loop decides what to do.

_{Architect Mode on a real request: a full design package, reviewable before any code exists —
not just this one file, the whole architecture/ package on the left.}

Before — the build, verified and running. Same restaurant system: guest ordering, a kitchen display, floor dispatch, and manager admin, with real allergen and dietary data.	After — the Designer agent wrote DESIGN.md and applied it: one dark surface system, the accent colour carried through, real elevation, tighter type. Same content, no functional change.

What it is

Most "prompt to app" tools are a product with an engine hidden inside. Zelyq is the engine, and it is
built so that nothing about it is magic and nothing is locked in:

• One execution seam. Every filesystem and shell operation goes through a single
  RuntimeDriver interface, so nothing above it knows where the code runs. local — child
  processes on your machine — is the zero-setup default. container is the same with agent shell
  commands and the dev server preview jailed one container per project. remote speaks a
  documented HTTP protocol to a runtime host, and a reference host
  ships in apps/runtime-host; one conformance suite runs against all three drivers, so they are
  provably interchangeable. Isolation is partial — container mode always blocks one project's
  container from reaching another's and blocks the cloud metadata endpoint, but does not otherwise
  filter outbound network access unless you opt into ZELYQ_CONTAINER_EGRESS_ALLOWLIST, which you
  name and maintain yourself. Read
  SECURITY.md before deploying.
• Bring your own model — cloud or your own machine. Claude, Gemini, OpenAI, DeepSeek, Mistral,
  Grok, Groq, or OpenRouter, chosen with one variable and a key. Or point ZELYQ_PROVIDER=custom at
  anything speaking the OpenAI dialect — Ollama, vLLM, LM Studio, a gateway of your own — and nothing
  about your project ever leaves your network. No proxy, no Zelyq account, no telemetry, either way.
• Every turn is a change you can inspect and undo. A snapshot before each turn, a diff of exactly
  what changed, one-click revert to any turn — and an audit log of who did what, once more than one
  person is working on an instance.
• Boring, inspectable storage. SQLite by default (one file), PostgreSQL when you scale. Project
  files are plain files on disk — you can cd into them and take them with you.
• Web or mobile. Pick React + Vite or Expo — React Native when you create a project.
  The Expo stack previews in the browser via Expo web, and the agent knows it's React Native —
  it builds View/Text/Expo Router, not div. Device and store builds are a separate step.
• /clone <url> — rebuild a live site, page for page. The agent visits the URL with a real
  browser, walks the pages, and rebuilds it in your project's framework: a REPLICA.md plan
  first, then the screens, with the real images and fonts mirrored in (substitutes logged where
  it couldn't get one), and a screenshot-diff loop against the original. Every fetch is
  SSRF-guarded — public hosts only. Only clone what you own or have permission to reproduce.
• Image Studio, and an agent that can use it. A signed-in page for generating original images
  from a prompt (OpenAI, Google, or xAI — your key, billed to you), with a private library, reference
  images, and durable history. Switch it on for a project and the agent can generate artwork for the
  app it is building, reuse an image you made yourself, and place either into the project. Anything
  it generates lands in your own library. It is off by default per project, because each image
  spends money, and bounded by a per-hour and a per-conversation limit you set. The agent is told to
  use real stock photography for anything your copy claims is real — a generated landmark is not a
  photograph of it. See Image Studio and
  agent integration.
• Video Studio. A signed-in page for generating short clips from a prompt, or animating a still
  image — Google (Veo) or xAI (Grok Imagine), your key, billed to you. Text-to-video and
  image-to-video, with the ratio, duration, resolution and audio options each model actually
  supports; a starting frame can be uploaded or picked from your Image Studio library. Jobs are long
  and asynchronous, so they survive a refresh and a server restart: the provider's operation handle
  is persisted, polling resumes on boot, and a submission whose outcome cannot be established says
  so rather than quietly generating (and billing) a second time. Finished clips are saved to your own
  storage — they keep playing after the provider's temporary URL expires — and stream back with HTTP
  range support so seeking works. A finished clip can also be split into a numbered image
  sequence — WebP, JPEG, PNG or AVIF, with a poster and a manifest — which is exactly what a
  scroll-scrubbed hero paints onto a canvas. See Video Studio and
  frame export.
• /video and /cinematic — moving footage in a page, built the right way. /video puts a
  muted loop behind a section; /cinematic makes a section play as you scroll, frame by frame on a
  canvas. The agent generates the footage itself and knows which technique the request calls for —
  a loop when the motion is ambient, a scrubbed sequence when it must follow scroll position, and
  real stock photography for anything the copy claims is real. Off per project until you switch it
  on, because clips cost real money. See
  video agent integration.
• /figma <link> — build from a Figma frame. Connect Figma in Settings (OAuth; the token
  stays on the server). Paste a frame's link and the agent pulls its node tree, a render, the
  assets, and the design tokens, then rebuilds it in your project — auto-layout becomes
  flexbox, Variables become the Tailwind theme — and diffs against the render.

Status

Early, and honest about it. The end-to-end path works — create a project, prompt the agent, watch
it read and edit files, run a live preview — and the interfaces around it were deliberately settled
first. Expect breaking changes before 1.0.

Two limits worth knowing before you invest time. There is no sandbox in local mode: agent shell
commands run as your own user, so that mode is for one trusted developer on one machine — read the
threat model before deploying it anywhere
else. And container mode's outbound network access is unfiltered by default — it blocks the
cloud metadata endpoint and cross-project reachability, but a project can otherwise reach anything on
your network unless you opt into ZELYQ_CONTAINER_EGRESS_ALLOWLIST yourself. See the
roadmap for what is next and what is explicitly out of scope.

Quickstart

# Requires Node >= 20.12 and pnpm >= 9
git clone https://github.com/CrowPus/Zelyq.git
cd Zelyq
pnpm install

cp .env.example .env
# Claude:  ANTHROPIC_API_KEY=sk-ant-...
# Gemini:  ZELYQ_PROVIDER=google and GEMINI_API_KEY=...
# OpenAI, or your own model on your own machine — see Models below

pnpm dev            # builds the libraries, then web :5173 · server :8787 · agent :8788

Open http://localhost:5173, create a project, and type what you want built. The first preview runs
npm install, so give it a minute.

Prefer containers? docker compose -f docker/docker-compose.yml up — see
self-hosting.

How it works

Three processes over four libraries. The agent never touches your disk directly; it goes through the
runtime driver, which is the seam that makes local and cloud identical.

        ┌───────────────┐
        │  apps/web     │  React + Vite — chat, file tree, editor, live preview
        └───────┬───────┘
                │  REST + WebSocket
        ┌───────▼───────┐
        │  apps/server  │  Fastify. Projects, files, previews, snapshots.
        │               │  Owns the database. Relays agent events to the browser.
        └───────┬───────┘
                │  HTTP + SSE
        ┌───────▼───────┐
        │  apps/agent   │  Runs the model loop, executes tools, streams events.
        └───────┬───────┘
                │  RuntimeDriver  (the only path to disk or shell)
     ┌──────────┴───────────┐
┌────▼─────┐        ┌───────▼────────┐
│  local   │        │     remote     │  container / VM / k8s runtime host
│ child_   │        │  HTTP contract │
│ process  │        │                │
└──────────┘        └────────────────┘

Model vendors sit behind a ModelProvider interface. Each keeps its own native conversation history,
because Anthropic requires thinking blocks echoed back unchanged and Gemini requires thought
signatures preserved across tool calls — flattening both into one format loses what the next request
needs.

Full detail: docs/architecture.md.

Models

Only the selected provider's key is needed. custom also needs ZELYQ_MODEL_BASE_URL pointed at your
endpoint (e.g. http://localhost:11434/v1 for Ollama) — see .env.example. Tested
live against a local, CPU-only 8B model: real tool calls, real self-correction from a validation error,
same behaviour as the cloud providers — just slower without a GPU.

Adding another provider is a registry entry plus one implementation — nothing in the server, the UI,
or the tools changes.

Local vs. cloud

One variable (ZELYQ_RUNTIME) moves between them. No code changes.

Configuration

Everything is an environment variable, and most of it can also be set in Settings inside the app,
so an instance can be run by someone who never opens a terminal — including entering the model API
key. The environment always wins; fields it supplies appear locked in the UI, labelled with the
variable that supplies them, so the two can never disagree silently.

Keys entered through Settings are encrypted with AES-256-GCM before storage and never sent back to
the browser. Only an instance administrator — the first account created — can see or change them.

Access control

Everyone signs in, and every route checks who they are. Projects belong to a team; your role in that
team decides what you can do:

The first account created owns the instance; set ZELYQ_ALLOW_REGISTRATION=false afterwards so
people join by invitation rather than by signing themselves up.

Roles are not a sandbox. An editor can make the agent run shell commands, which in local mode run
as the server's user — give editor to people you would trust with a shell on that machine.

Security

Local mode runs generated code on your machine with your permissions. It is meant for projects you
trust, on your own machine. It is not a sandbox.

For anything multi-tenant or internet-reachable, run the remote runtime with container isolation. The
threat model, and what Zelyq does and does not protect against, is written out in
SECURITY.md. Read it before you deploy.

Contributing

Issues, discussions, and pull requests are welcome. CONTRIBUTING.md covers the dev
loop, the repository layout, and where a given change usually belongs. Everyone participating follows
the Code of Conduct.

License

Zelyq is open source, licensed under the GNU AGPL-3.0. Run it,
modify it, self-host it, fork it. If you run a modified Zelyq as a service other
people use over a network, the AGPL requires you to offer them your source.

A commercial license — the same code without the AGPL's network-source
requirement — is available for embedding Zelyq in a closed-source product, or for
organisations whose policy blocks AGPL software: [email protected].
Features designated "Zelyq Enterprise" (ee/ paths) are a separate paid
subscription under the Zelyq Enterprise License.

See LICENSING.md for the plain-language version. Releases up to
and including v0.1.0 remain available under Apache-2.0.

© 2026 Dee Empire. "Zelyq" and the Zelyq logo are
trademarks of Dee Empire. Commercial licensing and support: [email protected].