Talorys
A single-user personal AI agent you deploy into your own Cloudflare account with one command — chat, memory, tasks, notes and scheduled reminders.
- Source repo
- rociiu/talorys
- Stars
- ★ 949
- Last updated
- today
- License
- MIT
- Primary language
- TypeScript
- FA score
- 63/100 · Some gaps
At a glance
- Works with
- Platform-specific
- You'll need
- Typical use
- A solo developer who wants a personal assistant inside their existing Cloudflare account without subscribing to another SaaS, staying within free-tier quotas.
- Main limitation
- Hard Cloudflare dependency: the product runs on Cloudflare Pages, Workers, Durable Objects (SQLite) and Workers AI, so there is no documented path to run the same product on another cloud or fully locally.
- Source review
- 63/100 · Some gaps
What does this agent do, and when should you use it?
Talorys is an open-source, single-user personal AI assistant that runs entirely inside your own Cloudflare account; the maintainers operate no server, database or account. The UI is a React app on Cloudflare Pages whose /api/* calls run through a Pages Function that forwards them over a service binding to a private Worker (Hono router) deployed with workers_dev: false and preview_urls: false, so it has no public URL. The brain is a Cloudflare Agents SDK Durable Object named TalorysAgent holding all conversations, memories, tasks, notes, projects, automations, sessions and settings in SQLite, with scheduling handled by Durable Object alarms rather than an always-on machine. Model calls go to Workers AI using @cf/zai-org/glm-4.7-flash with streaming and tool calling, and chat responses stream end-to-end as Server-Sent Events. Authentication and authorization happen inside the Worker; the installer hashes the owner password locally with PBKDF2-SHA256 and stores it only as a Cloudflare secret. When Workers AI is unavailable or the daily quota is exhausted, tasks, notes, memories and reminders keep working. The repository states there is no telemetry, analytics, tracking or advertising code.
Talorys bundles chat, durable memory, tasks, notes, projects and scheduled automations into one self-hosted service. A React/Vite frontend on Cloudflare Pages routes /api/* through functions/api/[[path]].ts, which forwards to a private Hono Worker via a service binding; the Worker performs authentication and calls getAgentByName("personal-agent") to reach the TalorysAgent Durable Object. That object persists conversations, memories, tasks, notes, projects, automations, sessions, settings and usage in SQLite tables, and uses Durable Object alarms to fire one-time reminders, recurring schedules and daily task digests into an in-app notification center. Chat turns call Workers AI's @cf/zai-org/glm-4.7-flash for streaming generation plus tool calling, so you can add tasks or notes from natural language ("Add a task to review my project tomorrow"). Optional semantic memory recall is off by default and can be turned on via the Semantic memory recall switch in Settings → AI or installed with --semantic; memory history keeps superseded facts as past facts instead of treating them as current. Settings → Privacy exports and imports talorys-backup.json, with imports treated as untrusted (imported automations arrive paused). CLI subcommands include install, update, status, doctor and reset-password.
- A solo developer who wants a personal assistant inside their existing Cloudflare account without subscribing to another SaaS, staying within free-tier quotas.
- Someone who needs one-off and recurring reminders ("remind me to review my project tomorrow") but does not want to keep a server or laptop always online.
- A user collecting long-lived preferences plus project notes and tasks who wants a single place with view/edit/delete control and portable JSON backups.
- A privacy-conscious individual who wants conversation and memory data to stay inside resources they own rather than a vendor-hosted account.
- A developer already using Workers, Pages and Wrangler who wants to reuse the same account, credentials and tooling for a self-hosted assistant.
- A single owner using multiple personal devices, signing in with one owner password and managing sessions under Settings → Security.
How do you install or deploy this agent?
Requirements: Node.js 22+, a Cloudflare account, and permission to edit Workers and Pages. The documented one-command install is:
npx create-talorys@latestThe installer checks Node.js, verifies or opens Cloudflare authorization in your browser, lets you pick an account and an agent name, asks for an owner password (hidden, strength-checked, hashed locally with PBKDF2-SHA256 and stored only as a Cloudflare secret), generates a 256-bit session secret and unique resource names, deploys the private Worker with its SQLite Durable Object, creates and deploys the Pages project with the service binding, then verifies the live deployment without running AI inference.
Non-interactive install (set CLOUDFLARE_API_TOKEN if you are not already logged in):
TALORYS_OWNER_PASSWORD=... npx create-talorys@latest --yes --account-id <id>If you use an API token instead of browser OAuth, it needs: Account › Workers Scripts › Edit, Account › Cloudflare Pages › Edit, Account › Workers AI › Read, Account › Account Settings › Read, and optionally User › User Details › Read.
It writes a talorys/ directory containing talorys.json (installation id, account id, resource names, URL — no secrets) plus the deployable artifacts; keep it for updates.
Local development from source:
git clone https://github.com/rociiu/talorys.git
cd talorys
npm install
npm run devHow do you use this agent?
Open the https://….pages.dev URL the installer prints, enter your owner password, and start chatting. Sign in from any number of devices — they are all the same owner — and manage sessions under Settings → Security.
Forgot the password? From your talorys/ directory (replaces the password secret and signs out every device):
npx create-talorys@latest reset-passwordUpdate, status and diagnostics from the same directory:
npx create-talorys@latest update
npx create-talorys@latest status
npx create-talorys@latest doctorFor local development, npm run dev starts the agent Worker (wrangler dev, port 8787), the Pages Function proxy with its service binding (wrangler pages dev, port 8788) and the Vite UI (http://localhost:5173) in one terminal, creates apps/agent/.dev.vars with the local password talorys-dev-password (override with TALORYS_DEV_PASSWORD), and uses the deterministic mock AI provider so no Cloudflare login is needed:
npm run build
npm test
npm run test:e2e
npm run test:pack
npm run typecheck
npm run lintIn-app backup and restore live under Settings → Privacy: Download backup produces talorys-backup.json, and Import validates the file and merges it in one transaction.
What are this agent's strengths and limitations?
- Clear data boundary: all conversations, memories, tasks and settings live in a single SQLite-backed Durable Object inside your own Cloudflare account, and the project states it ships no telemetry, analytics, tracking or advertising code.
- One-command deployment: npx create-talorys@latest creates the Worker, the Pages project, secrets and the service binding, then verifies the live deployment — no separate database, object store or KV to provision.
- Documented graceful degradation: tasks, notes, memories and reminders keep working when Workers AI is unavailable or the daily allocation is used up, and simple reminders and task digests never use AI.
- Update path that preserves state: update redeploys to the same resources, the Durable Object namespace is never recreated (migrations are append-only), the owner password and sessions are kept, and schema migrations run automatically and transactionally.
- Backup and recovery are first-class: a JSON export covers conversations, memories, tasks, notes, projects, settings, automations and memory history, with transactional merge on import.
- Security model is enforced server-side: authorization happens in the Worker, the agent Worker has no public URL, and the owner password is hashed locally with PBKDF2-SHA256 and stored only as a secret.
- Hard Cloudflare dependency: the product runs on Cloudflare Pages, Workers, Durable Objects (SQLite) and Workers AI, so there is no documented path to run the same product on another cloud or fully locally.
- The chat model is fixed to Workers AI's @cf/zai-org/glm-4.7-flash; the repository documents no adapter for OpenAI, Anthropic or other providers.
- You must own and authorize a Cloudflare account, and using an API token requires edit-level permissions on Workers Scripts and Pages.
- Free-tier limits are account-level (requests, Durable Object usage, a daily Workers AI Neuron allocation) and set by Cloudflare, so they can change and paid plans bill beyond included amounts.
- Single-user architecture: no signup, accounts or teams, so shared/multi-user workflows, role separation and collaborative auditing are out of scope.
- Deployment health checks can lag: new pages.dev sites may take a few minutes to pass verification, and doctor only diagnoses the deployment rather than changing Cloudflare-side state.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Talorys This agent | 63 · Some gaps | — | ★ 949 | today | TypeScript | — |
| GAIA — Personal AI Assistant | 73 · Some gaps | Hosted serviceFreemium | ★ 309 | today | Python | — |
| Kody Personal Assistant Platform | 70 · Some gaps | CLIFree + model costs | ★ 784 | today | TypeScript | — |
| Eclaire | 47 · Major gaps | Self-hosted serviceFree | ★ 924 | 5mo ago | TypeScript | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Least privilege: the Worker is deployed with workers_dev:false and preview_urls:false and has no public URL, the browser reaches it only via a Pages Function service binding, and the required Cloudflare permissions are enumerated; however no actual wrangler config or binding file is provided to corroborate, so 2. User confirmation: destructive tools only create proposals, and tests cover approve/decline/expire/re-approve, CSRF header and anonymous rejection, so 3. Data flow transparency: README states data lives in the user's account, no telemetry, and Workers AI processes messages and memories, but there is no field-level data-flow inventory, so 2. Sensitive data: password hashed locally with PBKDF2-SHA256, 256-bit session secret, exports exclude sessions and credentials, but no key rotation or at-rest encryption detail, so 2. Dependency security: only an esbuild override is visible; no lockfile audit or Dependabot/SCA evidence, so 1. External effects: installer does not enable paid services, imported automations arrive paused, no data deletion, but real-account side effects are covered only by an optional smoke test, so 2. Rollback: migrations are transactional and roll back on failure, updates do not recreate the DO namespace, imports are idempotent, but no explicit uninstall/rollback procedure, so 2. Source attribution: README credits contributors and MIT copyright, but publisher identity is unverified with no signing or provenance, so 1.
Self-consistency: README architecture, service list and test assertions (migrations, budget, approvals) align, but no actual wrangler/binding files were provided to cross-check, so 2. Dependency availability: engines require Node>=22, dependencies use ^ ranges and no lockfile evidence, so reproducible install cannot be confirmed, 1. Failure messages: AI quota/capacity errors map to friendly codes, cancellation is recorded as cancelled, validation returns typed errors, but no full error catalogue is shown, so 2.
Audience and scenarios: targets a single-user personal assistant covering chat, memory, tasks, notes and reminders; scenarios are clear but multi-user or team use is not covered, so 2. Capability boundaries: explicitly single-user, no signup, no teams, free-tier limits, graceful degradation when AI is unavailable; boundaries are well stated, so 2. Trigger precision: automations support once/daily/weekly/interval, reject past times and impossible dates, DST logic lives in the shared package, but full trigger-rule documentation is not shown, so 2. Environment fit: targets Cloudflare free plan, Node 22+, local mock development; environment assumptions are explicit but no other deployment targets, so 2.
Information architecture: README is clearly sectioned and the repository layout is listed, but there is no AGENTS.md or machine-readable manifest, so 2. Install notes: one-command install, non-interactive mode, permission list and troubleshooting table are thorough, so 3. Naming stability: resource names talorys-<id>-* and package names are stable, but version 0.1.0 with no naming compatibility promise, so 2. Examples and FAQ: screenshots, command examples and a troubleshooting table exist, but no standalone FAQ or broader use cases, so 2. Known limitations: free-tier quotas, AI-unavailable degradation and single-user limits are stated, but not consolidated, so 2. License: full MIT text present and referenced in README, so 3. Versioning and changelog: only package.json version 0.1.0, no CHANGELOG or release history, so 1. Maintenance responsibility: SECURITY.md gives response timelines and an update path, but the publisher is unverified and there is no governance or support commitment, so 1.
Output usability: SSE streaming, Markdown, tool activity indicators and a notification center make output usable, but no actual output samples are shown, so 2. Marginal value: provides a private personal assistant inside the user's own Cloudflare account, differentiating it from generic chat, but features overlap with common personal assistants, so 2. Cost benefit: free-plan friendly, no telemetry, non-AI features keep working after AI quota is exhausted; cost control is explicit but quotas and billing depend on Cloudflare and are not quantified, so 2.
Claim traceability: README claims mostly correspond to tests, but there is no claim-to-file/line mapping, so 1. Cross-source corroboration: README, SECURITY.md, tests and the CI workflow corroborate key behaviours, so 2. Fact/inference separation: docs distinguish design intent from test assertions, but some security claims (e.g. no telemetry) rest on assertion alone, so 2.
- Publisher identity is unverified; verify package provenance and signatures before installing.
- Dependencies use ^ ranges with no lockfile evidence, so installs may not be reproducible; pin versions and audit dependencies.
- No CHANGELOG or release history and version is only 0.1.0; confirm changes before upgrading.
- Real-account side effects are covered only by an optional smoke test; validate in a test account before production use.
- Security claims (e.g. no telemetry, no public URL) rest mainly on documentation assertions without corroborating config files.