Your personal app platform

From an idea to a live app — without managing servers

You describe what you want in plain language. Claude writes and fixes the code in the cloud. Every change you keep goes live automatically at your-app.l.eyri.app with HTTPS. This page explains what you can build, how to start, what it costs, and where the limits are.

1 What you can build right now

With the current setup you can ship real, internet-facing web apps — by yourself, by talking to Claude.

Web apps & PWAs

Dashboards, trackers, tools, small SaaS — anything that runs in a browser. They can be installable on a phone home screen (PWA).

Apps with a backend

A small server, an API, saved data, scheduled jobs — not just static pages.

AI features inside the app

Let your app call Claude (or other models) — explanations, summaries, chat, generation — billed per use.

Automatic deployment

Keep a change → it builds and goes live on its own, with a real domain and HTTPS.

Many apps, one server

Each app gets its own address app.l.eyri.app. Spinning up a new one is a few minutes.

Self-checking quality

Tests run on a schedule; when something breaks, an AI agent is asked to fix it and opens a proposal for you.

The first app on this platform — MarathonTrainer — was built and deployed exactly this way.

2 Getting started — entirely in the cloud

No installs on your computer. You only need a browser and the two accounts below.

  1. Open Claude. Go to claude.ai and sign in. This is where you'll do all the building — by chatting.
  2. Describe your idea. Tell Claude what you want in plain words: "Build a small web app that tracks my reading list, with a page per book." Claude asks clarifying questions, then writes the code in a cloud workspace connected to GitHub.
  3. Watch it take shape. Claude shows you a preview and explains what it did. Ask for changes the same way you'd ask a person: "make the buttons bigger," "add a search box."
  4. Send it live. When you're happy, Claude saves the change (a "push" to the main branch). That automatically builds the app and deploys it. A minute or two later it's live at your-app.l.eyri.app with HTTPS.
  5. Use it from anywhere. Open the address on your phone or laptop. On a phone you can usually Add to Home Screen so it behaves like an app.
  6. Fixing issues. If something looks wrong, just tell Claude. For bugs the tests catch on their own, an AI agent is asked to investigate and opens a proposed fix (a "PR") for you to approve — you stay in control. Anything that needs a real decision becomes a tracked issue with a one-click way to hand it to a cloud session.
First time only: create a free GitHub account (where the code and the auto-deploy live) and connect it to Claude. After that, building is just chatting.

3 What it costs

Three separate things can cost money. You can start with just the first.

WhatPriceWhen you need it
Claude Pro
the AI that builds your apps
$20 / mo From day one — this is your "developer." Next tier: Claude Max ($100 or $200/mo) for much more usage if you build a lot.
The server (VPS)
where your apps live online
≈ 830 ₽ / mo
(~$9)
when needed Only once you want apps reachable on the internet 24/7. One server hosts many apps.
AI used inside your app
e.g. an "explain" button that calls Claude
pay per use Only if your app itself calls an AI. You pre-load credit (e.g. $5) and it's drawn down per request.

"Pay per use" in plain numbers

When your app calls Claude, you pay for the size of each request — but you don't have to think in those units. A practical rule of thumb for a typical short request (like MarathonTrainer's "explain this workout"):

≈ 1–1.5¢

per "explain" request

≈ 400–500

requests for $5 of credit

≈ 1,500+

requests for $20

Rough estimates for a Claude Sonnet-class model on short prompts; a longer or chattier feature costs more per call. You set a spending limit, so it can never surprise you.

Cheapest way to start: just Claude Pro ($20/mo). Build and preview as much as you like. Add the server only when you want something live; add in-app AI credit only if an app needs it.

4 How it works under the hood

For the curious or technical reader. You don't need any of this to use the platform.

push to main ─► GitHub Actions (CI/CD) │ build a container image │ push it to the registry (GHCR) ▼ VPS (Ubuntu + Docker) ┌───────────────────────────────────────────────┐ │ Traefik :80 → :443 automatic HTTPS │ │ routes by hostname ──► one container/app │ │ app-a.l.eyri.app · app-b.l.eyri.app · … │ └───────────────────────────────────────────────┘

Stack

  • GitHub + Actions — source of truth and the CI/CD engine.
  • Docker — each app ships as a self-contained image.
  • GHCR — private registry for those images.
  • Traefik v3 — reverse proxy; routes by domain, issues free Let's Encrypt certificates automatically.
  • One VPS — a small Ubuntu server hosting every app side by side.

CI/CD & quality governance

  • Every push runs unit tests; they must pass before an app can deploy.
  • Nightly the unit tests run on a schedule to catch drift.
  • Friday night end-to-end browser tests run against a fresh build.
  • On failure a deduplicated issue is filed and handed to an AI agent (@claude) to fix.
  • Fixes arrive as PRs — never auto-merged. You review and approve.

Adding a new app is one command plus a push — the platform creates its folder, certificate and route on first deploy. No manual server work.

5 What it can't do (yet)

Honest boundaries, so you know when you'd need to change the setup.

cloud limits Not buildable purely in the cloud

  • Native mobile apps (App Store / Google Play). You can build an installable PWA instead, which covers most needs.
  • Desktop / native programs that must be installed on a computer.
  • Anything needing special hardware — e.g. training AI models on GPUs.
  • Work that needs your local machine — reading files on your PC, USB devices, etc.

setup limits Not possible without changing the platform

  • Always-on background processing (heavy queues, real-time streaming at scale).
  • Large managed databases or big file storage — the current server is modest; these need adding.
  • High traffic — one small VPS suits personal and small projects, not millions of users.
  • Strict compliance / isolation needs (separate networks, audited infrastructure).

None of these are dead ends — they're "next step" decisions. When you hit one, that's the moment to add a piece of infrastructure, and the same chat-with-Claude workflow helps you do it.