Everything WebDonkey does.

The sidebar is sorted by where the work happens: Local for everything on your Mac, Remote for everything on your servers, then Tools and Account & Help. The dashboard sits above them, Settings at the very bottom. This page walks through the app in exactly that order. Entries you do not need can be hidden in Settings. Collapsed, only the icon column remains.

On the left: Start all, Stop all, Restart and New site. On the right, a badge tells you whether you are on Free or Premium, and a dot with a counter shows how many services are running. Click it for the list, to stop or restart any of them from whatever page is open. Next to it sit the running uploads and downloads of the remote file manager.

If the front proxy or a service cannot start because another program holds its port, a notice under the top bar names that program. A button such as Free port 3306 ends it and then restarts the service; for the front proxy it is Free ports 80/443. If the DDEV router holds the ports, Move DDEV router puts it on other ports. WebDonkey does not free a system process, and the notice says so.

Next to the version number in the sidebar sits the Changelog link. One click opens the version history: what changed in each version.

The bell at the top of the sidebar collects what happened: finished installs, downloads and backups, scheduled tasks that ran, available updates, crashed processes, new mail in Mailpit, subscriptions due, state changes in the monitor and a Claude waiting for your input. Which messages you get is up to you in the settings, each kind on its own.

At the bottom of the sidebar. Pick what it is about and the app opens the right channel in your browser: the community for a question or a small glitch, a ticket that gets tracked and answered for a real bug.

At the bottom of the sidebar you switch between Aurora Dark, Arctic Light and System, with Premium also Sunset, Sunrise and Galaxy, plus your own themes. Manage themes… takes you to the Themes page. Try it on this page: the switch in the bar on the left swaps every screenshot at once.

You switch between pages without losing anything: tabs, filters, search fields, the selected row, the scroll position, half-filled forms and unsaved editor content are still there when you come back. That holds while the app runs; the next start begins fresh.

On first launch a wizard takes you through setup in five steps: install Homebrew and nginx, allow writing /etc/hosts, start the front proxy on ports 80 and 443, trust the local root CA and, if you want, let scheduled tasks and backups run while the app is closed. Every step says beforehand what it does. Do this later puts a step off, and everything can be changed later in the settings.

Status, services, sites, quick actions, monitor, subscriptions, scheduled tasks, DDEV & Docker, toolbox, databases, certificates, project backups, notes, mail inbox, updates, PHP version, SSH hosts, sandbox, SFTP / SSH, remote backups, remote cron jobs, remote logs, workflows, Claude, AI and virtual machines. Almost every widget has an arrow to its page, and many can be filtered: only certain sites, only problems in the monitor, only your favourite tools. Widgets of pages you hide in the sidebar go with them.

Click Customize, then drag the tiles to where you want them. The grid has three fixed columns so nothing reshuffles when you resize the window. Six sizes per tile, a catalogue to add from, Full board lays out a wide selection at once, and Reset brings back the default.

22 tiles also come as real macOS widgets for the desktop and Notification Centre, among them service status, problems, my sites, monitor and subscriptions. Quick actions starts and stops all services and restarts the front proxy, PHP version switches the active CLI version. A tap on a widget opens the matching page in the app. The widgets only get data when WebDonkey has Full Disk Access; Settings › System shows whether it is missing.

The WebDonkey tab shows every site WebDonkey runs for you, with web server, PHP and Node version and status. From each row you open the site in the browser, its folder in Finder or the editor and a terminal in the project folder, switch it off or edit it. Free allows unlimited sites, three of them with SSL at a time.

Name, domain and aliases, document root and, if you like, a project folder of its own, web server, PHP and Node version and SSL. You choose the domain freely, such as shop.dev or client.local. Next to Create, Still needed lists what is missing before the button becomes active. Edit opens the same form, where switching web server or PHP version works too.

Eleven packages, from WordPress, Shopware 6, Laravel, Symfony and Drupal to Vite, Astro, Angular and Hugo, are set up with one click: the package installs the whole application when the site is created, with configuration, document root and, where it needs one, a database. WebDonkey checks beforehand what it needs and offers to install what is missing.

Projects with their own server, such as a Node project with npm start, get a serve command instead of a document root. WebDonkey starts the process, hands it a free port as PORT, and the front proxy passes the domain's requests on to it.

The diagnosis checks every layer between browser and file: do the document root and an index file exist, is the domain in /etc/hosts, are front proxy and web server running, is the PHP-FPM socket there and the vhost written, is the certificate issued and does port 443 accept connections? With nginx the syntax check of the configuration comes on top. Every line gets a green tick or a red cross, and Check again repeats the run after you have fixed something.

Websites you built in WebDonkey Pages that have no site here yet appear on the WebDonkey tab below the list, under From WebDonkey Pages. Set up locally creates them under a .test domain with PHP and starts them, Open in Pages jumps back to the Pages app. Sites set up this way carry the Pages badge in the list.

All DDEV projects on your Mac, with status and type. Start, stop, open in the browser, jump to the project folder, open a shell in the container. A detail area shows configuration, snapshots, logs, add-ons and a field for any ddev command. New projects are created right here.

Clicking a DDEV row opens its management with five tabs: Configuration, Snapshots, Logs, Add-ons and Command. You edit the configuration as a form or as YAML; Restart makes the changes take effect.

What your Docker daemon holds right now, whether Docker Desktop, Colima, OrbStack or Rancher Desktop provides it. Start, stop, restart and pause containers, open published ports in the browser, open a terminal inside a container. WebDonkey only talks to your own docker CLI and never touches your configuration.

A click on a container unfolds its details: ID, image, created, restart policy, command, usage, ports, networks, mounts and environment. The Logs switch shows its logs instead.

Next to the containers sit the Images, Volumes, Networks and Compose tabs. You get images with Pull, Clean up removes unused images, volumes or networks, and Compose projects you start or bring down and look at their file. Start container creates a new container from an image, with ports, environment variables, volumes and restart policy; the ports are only reachable on this Mac unless you put an address in front.

Installed shows what runs, with version, port and uptime, what is installed but off, under Also running the site processes and the front proxy, and below them your runtimes, tools, apps and AI CLIs. Discover lists what you can add, with the chips All, Services, Runtimes, Tools, Apps and AI CLIs; web servers, databases, cache, mail, search, queue and storage sit under Services. Every entry says what it brings. The star on an installed service marks it as a favourite, and it moves to the top.

Every version is installed separately and runs on its own. PHP shows it best: 8.2, 8.3 and 8.4 side by side, and you set one active. That is the one your terminal gets, because WebDonkey puts small launchers for php, composer and the rest in your path. Individual sites can still pin a different one.

Editors, database tools, Git clients, terminals and API tools you install right from the app, under Discover with the Apps chip. More than fifty programs are ready, each with a description and its pricing: open source, free, freemium or paid. On a fresh Mac that is the shortcut: go through one list instead of fifty download pages.

The command-line agents of the big providers, eleven of them, installed and kept up to date with one click. They then run in any terminal. Six of them, Aider, Qwen Code, Codex CLI, Goose, OpenCode and Crush, also run with Premium in the app's AI section, right in the embedded terminal against your local model.

Run check, at the bottom of Installed, tests every running service: does nginx answer, is the PHP-FPM socket there, does MySQL accept connections, does Redis say PONG. With latency per service, so you see when something gets sluggish. Apps and CLIs are not checked.

The status indicator at the top right of every page opens everything that is running: the front proxy, services and site processes, the last two with uptime. Restart and stop sit right in the row. The front proxy comes first, a crashed service right below it.

At start WebDonkey brings back what you used last, plus PHP and Node in the versions your sites need. On quit the app waits until every service has stopped cleanly, and after a crash it cleans up its own leftover processes without touching anyone else's.

Pick the server at the top; below it you see port, data directory and status. Databases are created with a name and dropped only after confirmation, one with tables only once you type its name. PostgreSQL databases can be renamed. With several versions installed you choose in the card which one runs on the next start; for MySQL and MariaDB every version line has its own databases and users.

You back up any MySQL, MariaDB or PostgreSQL database from its row into a file: SQL, gzipped or plain, for PostgreSQL also as a PostgreSQL archive, plus one CSV per table as a ZIP, or JSON. WebDonkey remembers format, file name and folder per database and never overwrites anything. Restore loads a .sql, .sql.gz or .dump file and, if you like, first makes an SQL backup of the current state.

Create database users with a password and access to a specific database, the way a project expects them in its .env. Removing a user is just as quick.

The card reads the permissions straight from the server instead of keeping a list of its own. You see either each database with the users who may access it, with their level, or each user with their databases.

Adminer runs as its own service and starts automatically when opened. Under Adminer opens with you pick database and user; Adminer prefills server, user and database on its login, and you enter the password there. Reload and Open externally sit in the card header; if Adminer does not start, Go to Services takes you to the Services page. With Premium Adminer runs right in the card, on Free you open it in the browser. Adminer does not support MongoDB, so there is no DB browser button there.

The WebDonkey entry is the app's own log: what it did by itself, mainly backups and scheduled tasks, and what went wrong. By default you only see errors and aborts of the last seven days; entries are kept for 90 days.

Register any readable file with a name: the shop's deprecation log, the blog's Laravel log. They appear as streams of their own and can be cleared when a run should start fresh.

Pick a file, give it a name, done. It then sits next to the service logs as an entry of its own and is followed live just the same. Handy for a project Laravel log or a file only your deployment writes.

Every service brings its streams: the web server's access and error log, the FPM log, the database log, and under Sites the access and error log of every site. Pick one and the app tails the file every one and a half seconds. Lines in common formats show level and time separately, and a stack trace sits folded under its entry. Search, Copy and Export as text sit above the list; Open file takes you to the editor for more.

An audit belongs to one of your projects from monitoring. You choose the kind of audit, Full audit, Section or Single pages, and what is checked: SEO, accessibility or both. Then the start address, target keywords, extra pages, the URL budget and the crawl settings: scope (only this subdomain, every subdomain of the domain or a directory), click depth, the pause between requests, robots.txt, URL parameters and exclusions. Password-protected pages are checked with basic auth.

Scan site fetches the website once the way the crawl does, reads robots.txt and the sitemaps and shows every address it found as a path tree; nothing is rated or saved. One click on a path takes it out of the audit, a second brings it back; the start address is always crawled. The row sits in the New audit dialog and on the Settings tab.

After a deployment the short round is usually enough: only the pages you enter, no crawl, no sitemap. Paste several lines at once, full URLs are cut to their path; twenty links are checked in a few seconds.

It only starts when you click, after a confirmation with scope, URL count, click depth, pace and the longest it can take. The audit runs on as a process of its own, even if you close WebDonkey. If you stop it, you get the report on everything so far, clearly marked as incomplete; an interrupted audit continues where it left off.

An overall score and one each for content, SEO and technical, plus the key figures and every finding sorted into errors, warnings and notices. 85 checks, from duplicate titles through canonical and hreflang errors and redirect chains to orphan pages and click depth. Every finding lists the pages it affects and can be ignored; notices cost no points.

Every finding by content, SEO and technical, each with its severity of error, warning or notice, which you can filter by. Each finding explains what it means and what you can do, with example addresses; notices never count against the score.

Every crawled address on its own, searchable and filterable by finding or status: status, title and description with their length, H1 and outline, canonical, language, words in the main content, click depth, link strength and where the incoming links come from. The page table is saved as CSV under Export at the top.

The website as a whole: security headers, redirects, robots.txt and sitemap, the server's speed, access for AI crawlers and the domain's mail records. A handful of requests and a few DNS lookups, and the result is there within seconds.

Images, scripts, stylesheets and fonts of the audited pages, each file requested once: what is broken, what is too heavy and what is served without compression or caching. The check is on by default and covers at most 5,000 files, the most used first; you can switch it off in the audit's settings.

Pages are checked against WCAG 2.2, level AA by default, A or AAA if you choose: with axe-core at desktop and mobile width and with checks of our own for text contrast on images, alt texts, link texts and autoplay. On the home page and one page per template, up to ten pages by default, WebDonkey also tests keyboard and focus, reflow at 320 px, 200% zoom and text spacing. Problems that come from a template are listed once, with every page they affect; a WCAG matrix shows each criterion and the history compares with the previous run. The check runs on its own or together with the SEO audit in one crawl, and for a single URL in the inspector, local .test sites included. It uses the Chrome, Chromium, Brave or Edge you already have and a checking module from npm that WebDonkey installs once; Node.js comes from the Services page. An automated check: it does not replace a full audit under BITV 2.0 / EN 301 549.

Findings come with images: the page with numbered markers and a crop of every spot. The home page and one page per template get more: simulations of colour vision deficiencies, blurred vision, low contrast and forced colours, reflow, 200% zoom and text spacing next to the normal view with a slider, and the tab order as a numbered path. So you can show your clients what is behind a finding. The images come from an automated check and do not replace a full audit under BITV 2.0 / EN 301 549.

URLs the audit found but deliberately did not fetch, each with its reason: robots.txt, exclusion, parameters, too deep, filter trap, link loop, nofollow or the URL limit. So you see what is missing before you treat it as a finding.

The last 30 audits with score, pages, errors, warnings and notices and the change against the run before; an audit that did not run to the end is a hollow dot in the chart. From the second run on, a chart shows how the score develops, so you see whether your work pays off.

How an audit crawls: scope, limits for URLs and click depth, pause and parallel requests, robots.txt, URL parameters, exclusions, the crawler's identity, external links and the resource check, plus Filter pages and the accessibility settings. Below them keywords and extra pages, for Single pages the list of pages. Changes apply from the next audit on; the current report stays as it is.

From the page table, Inspect examines a crawled page in detail, fetched with the audit's settings, keywords and login: status and redirects, load time, search result and social preview, findings, headings, keyword density, links, images and resources.

Check a single address without creating an audit: the page is fetched once and analysed in detail, and nothing is saved. You start it on the SEO page or from the ⌘K search.

The report as a designed PDF with SEO, accessibility or both in one file, the page table as CSV and the whole report as JSON. You enter your company name, logo and a contact line once in the settings under Reports; with your own sender, logo and name appear on the cover and in the footer, the contact line in the footer, and “Report for” with your client's name on the cover. The WebDonkey style stays, and the small “Created with WebDonkey” note can be switched off. The accessibility chapter itself states that it is an automated check and does not replace a full audit under BITV 2.0 / EN 301 549. Exporting works as soon as the first audit has finished.

Name, command, working directory and schedule. The command runs through your shell, so pipes, && and environment variables work. Switched off, a task only runs on demand.

A standard cron expression with five fields: minute, hour, day, month, weekday. Presets save you the writing, and the expression is checked before you save.

Normally scheduled tasks and backups run inside WebDonkey, and whatever was missed is caught up the next time you open it. If you like, WebDonkey hands the timing to macOS, and the nightly backup runs even with the app closed.

Each task is a card with its schedule, its last result and the captured output: OK in green, otherwise the exit code. Run now, pause and resume work right there.

At the top of every remote page and in dialogs that write or delete on the server it says Caution: working directly on the server. Switch it off with Don't show again or in the settings under Remote notices.

Name, host, port, user and password or key, via ssh-agent if you like. Existing hosts come over from ~/.ssh/config. Passwords and passphrases are stored encrypted (AES-256), with the key kept apart from the database. On first connect the server key is remembered; if it changes, the app asks before going on. In the list you sort connections into projects and search them, and the red colour tag marks production servers. If the server does not know your key yet, the app adds it with your password.

Every open connection becomes a tab above the terminal. That lets you work on several servers side by side, or several times on the same one, each session on its own.

A full terminal over SSH, with scrollback, resizing and colours. The terminal and the file manager share one connection, so one login covers both.

Pair a folder on your Mac with its counterpart on the server. Compare shows what differs, then Upload, Download or Sync in both directions, always with a preview first. Sync also carries deletions and shows conflicts instead of overwriting them; besides it there are Copy only and Mirror. Compared by size and date, replaced atomically, the old version is kept for 14 days, and Undo last sync brings the whole run back.

Two panes: local and remote. Upload, download, rename, move, delete, create folders, set chmod. Transfers carry on when you leave the page, and what you delete locally goes to the Trash.

The editor card below the file panes opens text files from your Mac or the server, with syntax colours. A dot marks unsaved changes; Save writes the file straight back.

If the server has a database entry, its database card with data, structure and SQL sits below the editor, as under Remote databases.

Name, server, the archive file name, the folders and files on the server, what is left out, databases with their format, where it is stored, on this Mac or on the server, schedule and retention. You pick the folders with Browse right on the server; a database can be backed up without any folder too.

Before every run WebDonkey checks the free space on the server, then dumps the databases, packs an uncompressed .tar on the server and downloads the archive if you want it on your Mac, with progress in per cent. A note names whatever the SSH user may not read.

Manual only, hourly, daily, weekly or a cron expression, with presets. The row shows the last and the next run, and a rule decides how many archives stay.

Every archive a Remote function created, newest first, with server and location. Download fetches archives on the server to your Mac; failed runs are marked.

Folders and databases of an archive back onto the server, each folder to its origin or to another target you map, with Replace folder or Merge. Before loading, WebDonkey always backs up the target database, and nothing is overwritten until you type its name to confirm.

If an archive holds folders and databases, its parts are listed below it: the files and one row per database. That way you restore only what you need.

Pick the server, give the log file by path or with Browse, name it. The first read fetches the last lines, every further one only what was added.

On opening, WebDonkey fetches the new lines and marks them. Live reads the log again every few seconds while it is shown, and on a schedule WebDonkey reads in the background while it is running, from every 30 seconds to a cron expression.

Lines in common formats (Apache, nginx, PHP and PHP-FPM, Laravel, syslog) get time and level, and a stack trace hangs folded at its line. Search, Copy and Export as text work as with local logs.

For each server connection you add the websites you look after. You pick the project folder, WebDonkey detects system and version and changes nothing. Active websites count: archiving frees a slot, reports and history stay readable. Above your quota the most recently added ones are locked, nothing is deleted. A system version that is not fully tested yet carries a Preview badge, and you confirm once more before every write to live. Unsupported versions, such as ones without security updates, carry Locked and get no deploy, only checks and backups.

You create the folder, an empty database and a subdomain in your hosting panel. WebDonkey checks everything before writing, only reads the live site and backs up its database first. The staging site is built with personal data replaced, defused (no mails, no scheduled tasks, access of external services cleared) and only then made visible, protected by Basic Auth or the system's maintenance mode. Refresh rebuilds it from live and shows first which changes would be lost.

A looked-after website comes to your Mac as a site with a .test address: files and database, personal data replaced, configuration adapted. You choose whether media files come along, and the same pre-check as for Fetch locally runs first. Try changes and updates there, then take them over one by one. Removing it deletes the site, its database and its folder on the Mac, the live website stays untouched.

WebDonkey compares every field in source and target with its state when the copy was made. Only fields that changed in the source are written. If the same field changed on live too, that is a conflict: you keep the live value or explicitly force the new one. Whatever a chosen object needs comes along, and deletions are shown but never taken over. After writing, WebDonkey reads every field back. You can take over products, categories, CMS pages, snippets and mail templates in Shopware, for example, or pages, posts, menus and settings in WordPress.

For simple websites without a system: between the project folder of a local site and the live folder, in both directions. You see a plan first, and only what you confirm runs. Every file is backed up before it is replaced or deleted, deleting needs a second yes, and the last transfer can be undone.

Plugins, themes and modules go from staging or a local copy to the target. WebDonkey checks versions and requirements, backs up the database and the extension's folder, and swaps the folder only once everything is ready. Then the system's own steps run, in Shopware the plugin update, for example. The old folder ends up outside the web root. If a step fails, it comes back, and you can restore the backup.

Before every takeover WebDonkey keeps the previous value of each field. Undo writes it back as long as live still holds the value taken over, otherwise it shows a conflict. The history lists every takeover with source, target and objects, and an interrupted one can be resumed or discarded. Undo works without an active maintenance package too.

Before WebDonkey writes to a website (staging, a takeover, an extension, a restore), it backs up the database and the files concerned on the server. If you like, it also copies them to your Mac, per website. The newest ten stay, and always the backup of the last takeover that was not undone. You find them with the website and under Remote backups. Before a restore WebDonkey counts what is new since and would be lost.

What is installed on the live site and what is newer: core and extensions of WordPress, Shopware and Magento, plus Composer and npm packages. The lookups run from your Mac while WebDonkey is running, daily by default. Updates are only shown, never run on live: you update in staging or the local copy, compare, then take the extension over.

The installed versions are matched on your Mac against public databases of known vulnerabilities, for WordPress with your own Wordfence key. On top come checksums of the files on the live server, compared with the base daily by default: new, changed and deleted files, executable files in upload folders above all. WebDonkey also checks WordPress core and plugins from wordpress.org against the official checksums.

The start page and up to ten more pages, captured at the widths 375, 768, 1280 and 1920 pixels, which you pick one by one, and compared pixel by pixel: live earlier and now (weekly against the base by default), live and staging, live and the local copy, before and after every takeover to live. Animations are off, common cookie banners hidden, and areas that keep changing you mask by selector, or WebDonkey leaves them out by itself.

A flow clicks through the website like a visitor: start page, login, search, cart, checkout. You start from a template and run it by hand, daily, weekly or monthly. Against the live site a flow stops before the buy button: WebDonkey never orders, pays, registers or sends a form there. Complete flows run against staging or the local copy.

For every website and month: uptime, SSL certificate, backups, updates, vulnerabilities, changed files, takeovers and Lighthouse scores, as a PDF with your name and logo for your clients. On the first of each month WebDonkey freezes the month before. If the Mac was off, it catches up at the next start. What was not measured says so.

Project folder and database come from the server to your Mac over SSH and become a site with a .test address. Projects with a database are fetched for Shopware 6, WordPress, WooCommerce and Magento 2. The server is only read, and WebDonkey detects the public folder or you name it. The copy is always made safe: database access to the local database, mails to Mailpit, scheduled tasks off, access of external services cleared. With Premium it runs straight away, with addresses on .test and Redis and the search service off. Customer data comes along unchanged, and you confirm first that you may fetch it. Only the maintenance package replaces it while fetching (pseudonymised).

Before anything is created on your Mac, WebDonkey checks whether the fetch will work: connection to the server, PHP on the server, project folder, document root, the database login, a way to back up the database, space on the server and on your Mac, a free local target and the database service on your Mac. Every point names the reason and the fix. With everything green the fetch starts straight away, with warnings only after Fetch anyway, with red not at all. Under Advanced you set the database access per connection and project folder: host, port, socket, database, user, password and dump program, prefilled from the project's configuration, with Test connection; WebDonkey stores the password encrypted. For the dump program you choose Automatic (recommended), one found on the server, Without dump program (PHP) or a path of your own. Automatic only takes mysqldump or mariadb-dump of the same kind as the database server, the closest version first, and tries each one beforehand; if none works, WebDonkey reads the database with PHP. That takes longer, the result is the same. The same check runs before every local test copy, and the stored access also applies to staging and to the backups before a write.

One HTML file with the state of the chosen websites and a bar per day of the last 90 days. No script, no outside request, no tracking. Save it as a file or upload it to a folder on your server, where it replaces the previous one in one step.

Under Check times you set, per website or for all, how often WebDonkey checks updates, vulnerabilities, files and visual comparisons: daily, weekly, monthly or off. The default is daily, weekly for the visual comparison. Checks run while your Mac is on, and a missed one follows after the next start. Flows have times of their own. You also store your Wordfence Intelligence key here for matching WordPress, kept encrypted on your Mac.

Without Premium you fetch a project locally and get a copy made safe, and Premium also makes it run. Everything else comes with the maintenance package: an add-on that needs a WebDonkey Premium licence and does not include it. It comes for 10, 30 or 100 websites, with add-ons for 10 more each, monthly or yearly, and only for business accounts. For more than 150 websites we make you an individual offer. When Premium ends, the maintenance package unlocks nothing any more; if it runs longer, it becomes a licence of its own that you can assign to a running Premium licence or cancel. Viewing, restoring backups, undo, deleting staging and archiving still work then.

With wd you drive WebDonkey from any terminal: services, sites, databases, logs, scheduled tasks and backups, plus saved SSH connections, the front proxy and Claude Code. wd edit opens files in the WebDonkey Editor, wd open a page of the app, and wd doctor names setup problems with their fix. Backups and SSH connections need Premium. Any output comes as JSON if you want it. The card checks whether wd is on your path and turns on "Tools in the terminal" with one click.

Create aliases with a name and a command, switch them on and off. WebDonkey writes them to its own file and includes it in your .zshrc with a marked block. Whatever your shell already knows is detected and can be adopted with one click.

All keys from ~/.ssh with name, type and fingerprint. Generate new keys as ed25519 or RSA 4096, with a comment and a passphrase if you like, copy the public part, delete old ones.

Host entries with alias, hostname, user, port and key. They go into their own file under ~/.ssh/config.d, included at the top of your SSH config. Your existing configuration is left untouched. After saving, WebDonkey checks whether logging in with the key works. If the key is not on the server yet, you enter the password once and WebDonkey adds the key there, like ssh-copy-id. The password is not stored.

Which server keys your machine knows, as a list. Remove entries when a server has been rebuilt instead of editing the file by hand.

Design the left part of your command line, across several lines too: folder, time, date, user, host, git branch, the result of the last command, $ or # and text of your own, plus frame and arrow characters such as ╔═ or ❯ and colours from the 256-colour palette, with a live preview. Save several designs and switch with one click, or go back to your own prompt from .zshrc; eight templates are free for everyone. Free keeps three own prompts, Premium any number.

Every workflow in a table with trigger, last run, next run and an on/off switch. A new workflow starts empty or from a template, such as the nightly database dump or the deploy by webhook; a template arrives switched off. Free uses three workflows.

Place nodes on the canvas and connect them with lines, add notes, undo with ⌘Z. On means the triggers start the workflow; Run starts it right away.

Every node is a step, sorted into triggers, logic, data, input and output, WebDonkey and AI. A click opens its form; the fields take expressions that reach the data of the steps before. Nodes marked Premium only run with Premium.

Items flow between the nodes; expressions reach them, the trigger, variables and secrets. Variables belong to one workflow or to all; a secret is stored encrypted and never exported.

Every node has settings of its own: retries, pause in between, time limit and what happens on an error. The run ends, carries on or takes the error output, where you can attach a notification, for example. Each workflow has its own settings too: description, time limit for a run, a message on failure and how many runs stay in the history.

Below the editor every run is listed step by step, with the items that went in and out, retries and duration. You cancel a run or run it again with the same trigger data. Free keeps the last 20 runs, Premium up to 200.

What a workflow keeps between runs, such as the last ID it saw; the Only new and Remember value nodes store it. You forget a single value on purpose, Reset clears everything, and the next run starts from scratch.

Conversations with history, model choice and memory budget at the top. Attach files and folders as context; the app shows how much of it fits the context window. Chats are Free.

Reusable experts with instructions and fixed paths as context: the Laravel expert knows your project, the SEO reviewer knows your copy. Start a chat and the context is already there. Premium.

Coding agents such as Aider or Qwen Code run in the embedded terminal against your local model. The app starts them without auto-approve flags; every change remains your decision. Premium.

The catalogue rates every model against your memory: Recommended, Runs or Too big for this Mac. Download with progress, remove, set default. Free.

You add any model from the Ollama library or Hugging Face by name, such as qwen3:8b. Once downloaded it appears in the list and can be chosen as the active model.

MCP servers currently running on this Mac, with client, kind, processes, CPU, memory, uptime and owner. A server starts with its client and shows here while it runs.

The MCP servers in your clients' configuration files, running or not, each with client, level and state. If a login is missing, the row says so.

Every client WebDonkey knows, the files it looked at and what came of it. This is where you learn why a server is missing from the lists.

Writes an MCP server into a client's configuration: a local command or a remote server with an address, with environment variables or headers if needed. Free adds two servers, Premium any number.

Starts a server as a test and asks what it offers: whether it answers and how fast, its protocol and how many tools, resources and prompts it has. With Premium you see the lists themselves and its error output.

Stop asks a running server to quit and tells you beforehand what that means for its client. With Premium you clean up orphaned servers whose client is gone in one go and read their logs.

If a server asks for a login, Log in handles it for the client that owns it, in the browser or in the terminal. This is free.

With Premium you edit entries, switch them on and off and copy them into other clients. Removing works on Free too. Where a client or entry cannot be written, it says read only, with the reason.

One card per currency with the amount per month and per year, the charges of the next 30 days and the number of active subscriptions. Yearly and other cycles count with their monthly share; currencies are not converted.

Name, website, price and currency, start date, billing cycle, end date, category, notice period in days, status (active, paused, cancelled), payment method and notes. Free manages up to six subscriptions.

From weekly to every two years in one click, or a rhythm of your own in days, weeks, months, quarters or years.

From start date and cycle WebDonkey works out the next due date and colours it by urgency. With a notice period, the row shows in good time until when you can still cancel.

Aurora Dark and Arctic Light ship with the app, along with System, which follows the macOS setting, and three finished Premium themes: Sunset, Sunrise and Galaxy. With Premium any of them can be copied as a starting point with Copy & edit: change the colours and the preview in the editor shows it straight away.

Save, edit and delete as many themes of your own as you like. Up to three can be waiting for the gallery at a time; they appear there once reviewed, and your name is never shown. A code from the gallery can be pasted on Free too.

Four decisions make a complete theme: text, borders, surfaces, the glass sheen and the background are derived from them, which is why a theme of your own still looks like WebDonkey. You start fresh, copy a built-in one or paste a code from the gallery.

Themes other WebDonkey users have shared, loaded straight from the shop, with search and sorting by New or Popular. Save adds one to your themes, on Free too. What has been approved stays in the gallery, even if you delete it locally.

Version, the licence list of the components used, your licence key and the language, plus the switch for whether remote pages show their word of caution. Paste the key from your customer account, activate, done; a seat moves with you to your next Mac. 16 languages; on first launch the app follows the system language.

WebDonkey looks for new versions by itself and shows the release notes; it only installs when you click. Only version, platform, architecture and the language of the release notes are sent, nothing about your projects.

Any action from the search can get a shortcut of its own: a key, a combination or a sequence such as G, then S. The app catches system shortcuts and duplicates and tells you who already has them.

Hide any page you do not need: it leaves the sidebar, the ⌘K search and the dashboard widget catalogue and comes back with one click. On Free you can also hide every Premium feature instead of seeing a lock everywhere.

Which messages you get, each kind switchable on its own, effective at once. A master switch silences everything and keeps your selection.

The default folder for new sites, the code editor for Open in editor, tools in the terminal (php, node and friends in the version from the app), port forwarding 80/443, sites on the local network, the local root CA and the hosts file sync.

Where WebDonkey hands over terminals, folders, code and databases. Automatic picks the WebDonkey Editor once it is installed, otherwise Finder, Terminal and WebDonkey's own DB browser; each setting shows what it currently picks.

The sender of the PDF reports for your clients, set once: company name, a contact line and your logo as PNG, JPEG or SVG up to 1 MB, on a light plate if you like. The name goes on the cover, name and contact line into the footer, and a preview shows it beforehand. The report keeps the WebDonkey style, and the “Created with WebDonkey” line can be switched off. Your own sender is part of the SEO or maintenance package.

Let tasks and backups run on schedule while the app is closed, the sandbox with its size and a reset, and system discovery.

Your whole setup as one zip file: sites, services, configs, certificates and what the pages keep, with you choosing what goes in. On import on another Mac it is rewritten to fit, which is how you move.

In the System tab: the macOS widgets, which only get their data with Full Disk Access, the safety copies of the app database before a new version first starts, and removing WebDonkey from this Mac.