01
Target-machine routing
Every tool call names its target machine. An IP is not an identity, a session is not an identity — the machine ID is; routing adds about five milliseconds.
Self-hosted · Your data
Digital employees, hired one role at a time
Put your business on autopilot
MagicFrog runs on your own servers. Reports, reconciliations, checks, follow-ups — your digital employees run them end to end, you sign the key decisions, and every step stays on the record.
The numbers are not a scoreboard — they are boundaries, each checkable in the docs or the artifacts.
6
verifiable security mechanisms — cite them straight in compliance reports
15
pages of core docs covering deployment and daily use
54
pages of documentation, from install to operations
1
command to start the server — at work the same day
Personal assistants handle life. Coding agents handle PRs. Who runs the business?
Personal agents book your flights. Coding agents fix your code. Business work lives in real machines, intranets and data — across three lines MagicFrog takes the shift.
01
Every action names its target machine
Browser, terminal, files — every operation carries an explicit target machine. Wrong target, offline machine, missing approval: the operation fails with a stated reason; the system never silently retries on another machine.
- Missing ID, mismatch, revocation, missing capability — all fail explicitly
- Resource handles stay bound to their original computerId
- Audit records name the machine that actually executed
- Targets are authorized twice: control plane, then device
02
Internal egress is an authorization, not an env var
When an agent reaches an internal system, it travels through a client tunnel you authorize explicitly. Dropped, expired, or revoked, the path closes at once — fail-closed, never back to direct.
- Egress choice is an explicit lifecycle
- Switching never reuses the old channel
- Revoking a grant takes effect within five seconds
- A tunnel that dies mid-session fails the connection at once
03
Existing machines join with one command
Run one enroll and an existing computer, VM, or server becomes an operable node. Unenrolling revokes access only — no shutdown, no reinstall, no touching its data.
- Enrollment is one command
- Device credentials are independent of account login
- Unenrolling revokes access only
- No shutdown, no reinstall, no touching its data
04
You process an event queue, not a chat you babysit
Whenever any agent in any task needs a human decision, the event lands in one global inbox. Work the queue — reply, approve, answer — and each response writes straight back into that task's session. Queue empty, nothing left to do.
- Four card kinds, one skeleton: approve, question, form, takeover
- Aggregated across all tasks, not just the open one
- Done means back to the conversation; empty queues are disabled
- Every card links back to the exact message
A day with your digital employees
Hand the work to your digital employees and sign what matters. After hours, the server keeps going.
01
Morning · Ops
Ask for yesterday's numbers. The compiled report is waiting when you open the console.
Diff · Explicit target routing
02
Afternoon · Engineering
Watch the build, catch the error, fix it, open the PR — you review only what matters.
Diff · Existing devices, zero rework
03
Afternoon · Admin
A batch of forms filled, checked, and submitted one by one, the path fully traceable.
Diff · Internal egress
04
After hours · Everyone
You clock out; the work keeps running. Next morning the results are summarized and waiting for review.
Diff · Existing devices, zero rework
A real enrollment capture: the CLI prints a one-time pairing code, you type it back, and the machine appears under your account.
A live session in the web console: task list, event inbox, and audit trail in one workbench.
Devices under the account: cloud computers beside enrolled real machines, each with status and probed capabilities.
One console, a whole digital team
Not a feature list — one discipline on one server: every step has a target, an approval, and a record.
02
Cloud and real machines side by side
The server provisions Linux and Windows cloud computers on its own host; your existing servers enroll with one command. Two targets, one authorization model.
03
Isolated browser sessions
Each session is a separate instance: own process, own profile, own port. Four concurrent sessions per machine; beyond that, explicit queues or refusals.
04
Memory in five dimensions
Account, user, agent, task, device — a Markdown memory tree on disk where the most specific dimension wins.
05
Triggers and watchers
Cron schedules run on plan; script watchers loop on target. Missed schedule slots are skipped, never replayed.
06
The event inbox
Approvals, questions, forms, and takeovers converge into one global queue, and answers write straight back into the task session.
07
Voice, fully self-hosted
Dictation and speech run on your own transcription and synthesis endpoints, loopback by default. No third-party voice cloud ever enters the chain.
08
The MCP market
The official registry plus custom sources merge into one catalog; browse on the web and send installs to your desktop client.
Every capability maps to a doc section — links go straight there, no detours.
Own it, or rent it
Same job, two cost structures — line by line.
01
Pricing
Owning MagicFrog
Deploy once, keep using it — never per seat
Self-hosting is free. No hosted tier, no hidden plans.
Renting an agent platform
Monthly fees that scale with every seat
02
Data boundary
Owning MagicFrog
Your data never leaves your doors
All data lives in one file in your data directory — backing up the volume backs up everything.
Renting an agent platform
Your data lives on someone else's servers
03
Continuity
Owning MagicFrog
Free to self-host, runs as long as you want
The server is a single executable: your host runs, it runs.
Renting an agent platform
Stop paying, service stops
Data ownership is not a promise — it is the deployment shape itself: a SQLite file on your volume, the field-encryption key in your hands.
You save more than money. You keep your data.
Three lines plus one queue form the skeleton of MagicFrog: machines have names, egress has authorization, devices join untouched, and humans only make the calls.
Run MagicFrog today
The client goes on your machine; the server, one command on your host.
01
Get the client
Desktop app and CLI, direct download.
02
One command for the server
A single-file server, curl and done.
03
Or hand it to your agent
Send the deploy skill; it executes by the doc.
All three channels end in the same place: your own server.
Rather not do it yourself?
Give this prompt to your agent; it deploys the server by the doc.
Deploy a MagicFrog server for me. 1. Fetch the deploy skill document at https://www.magicfrog.ai/agent-deploy/ (raw markdown at https://www.magicfrog.ai/agent-deploy.md). 2. Follow it exactly: install the single-file magicfrog-server, export the required environment, start it on port 4096, and finish the admin bootstrap and forced password change. 3. SSH connection details for the target server are provided by me: <fill in: host, port, user, key or password> 4. Stop and report back if any step fails; never substitute an undocumented command or skip a required environment variable. 5. When you finish, report the server URL (default http://localhost:4096) and the admin identifier so I can connect my client with --server <serverUrl>.
Three steps from download to your first hire
We detected your platform and you can switch manually. Steps can be revisited in any order.
Detected platform: ·Choose manually:
STEP / 01
Install the client
Downloads the magicfrog CLI into ~/.magicfrog/bin and updates your PATH.
curl -fsSL https://www.magicfrog.ai/install | bashSTEP / 02
Start the server
Installs the single-file magicfrog-server binary. Then follow Self-hosting to configure the admin account and run it.
curl -fsSL https://www.magicfrog.ai/install-server | bashSTEP / 03
Enroll a computer
Pairs an existing computer, VM, or server with your account as an operable node.
magicfrog enroll --server https://<host>:4096
Eight questions, answered before you deploy
Do I need a subscription or a hosted account?
No. MagicFrog is self-hosted software. Model access uses your own API keys, with no hosted tier and no bundled plan.
Can my existing computers join?
Yes. Run magicfrog enroll on the machine. After pairing it becomes an operable computer on your account.
What happens when a machine is offline?
Calls to it fail explicitly. Nothing is re-targeted to the local machine or another online machine.
Which operating systems are supported?
Linux, macOS, and Windows. Shell, file, and browser work are verified against real capability. Desktop control also depends on OS permission, such as Screen Recording on macOS.
Where does my data live?
On your server, in one SQLite file. Backups are a volume operation, and you hold the field encryption key.
Can I bring my own model provider?
Yes. Anthropic, OpenAI, and any OpenAI-compatible endpoint are BYOK channels. Local inference servers are discovered through built-in presets.
How many servers can I run?
One control plane orchestrates only the host it runs on. That is the LITE boundary, not a setting. Enrolled machines are outside it.
Do the installers need code signing?
No. Unsigned artifacts are legitimate deliverables and OS prompts are not product failures. Every artifact carries a SHA-256 digest and byte size.
What are the minimum requirements to self-host?
Any Linux VPS or your own server. The server is a single-file executable compiled from bun, with SQLite on disk in the data directory and no external database container.
Where does the one-command install come from?
curl -fsSL https://www.magicfrog.ai/install-server | bash installs the single-file server; the steps are in SELFHOST.md. You can also hand the /agent-deploy skill document to your agent to run it for you.
How do I connect the client after downloading?
The client ships unconfigured and connects in three steps: install the server on your host, install the client locally, then paste the server address into the server field on first launch. The download page builds the guide around the address you enter.
How do I enable Google OAuth login?
Configure the Google client id and secret in the admin backend, with strict redirect URI validation and an email domain allowlist. OAuth is off by default and the routes do not exist until then; the self-hosted account stays the primary login.
How do I set up HTTPS?
Two paths: use caddy as a one-step reverse proxy (a compose profile enables TLS termination automatically), or terminate TLS on your own reverse proxy. Behind a proxy, set MAGICFROG_TRUST_PROXY so the server trusts X-Forwarded-For/Proto.
Must the server and client run on the same machine?
No. Running them on different machines is the standard setup; the server listens on 0.0.0.0 by default precisely so clients on other devices can reach it. Point the client at the server address.
Where does data live and how do I back it up?
Server data lives in one SQLite file under the data directory you set. Backing up that directory is the backup; keep the field encryption key with it, because losing it makes the data unrecoverable.
Time to put digital employees to work
Give it a job, a team, a company — with every step on the record.
Installers carry checksums, verified on download.