Veilus, an anti-detect browser with an integrated automation layer, is the subject of a step-by-step walkthrough published on dev.to under the title "Introducing Veilus: Your First Hour, From Install to a Scheduled Script." The post is a community contribution and, per the source, was originally published on the Veilus blog, so its descriptions of the product come from the vendor's own material rather than independent testing. It is not a release announcement: the piece documents an existing workflow rather than a new version, and no version number or ship date is given in the supplied text.
Narrow and explicit is how the walkthrough frames its own scope: a single sitting, beginning with a fresh install and ending with a script that executes by itself each morning, while every step points to a documentation page for the full detail. How the claims ought to be read depends on that framing. What the author is recounting is a first-run experience rather than a benchmark of the browser, and no measurements of its own appear in the post.
Windows 10 or 11 (x64) is one supported platform, per the post, and macOS 13 or later on Apple Silicon is the other. On first launch, the author notes, the publisher goes unrecognised by either Windows or macOS, so one operating-system warning must be clicked through by the user — "More info → Run anyway" under Windows, or "Open Anyway" within Privacy & Security under macOS. Bundled into the installer, the browser itself is not; what the user does is open Settings → Engine & updates and download the build marked Latest, described in the post as Veilus's own Chromium build on which every profile runs. Automatically, the first engine downloaded becomes active.
Profile creation is the next documented step. The user clicks New profile and picks the operating system the profile should present. The post states the default is the computer's own OS and calls that the safer choice, because a profile for a different OS has to imitate more; the author says Veilus warns the user if a different OS is selected. The user then picks a market under Language & Region, or sets language and timezone manually, and creates the profile. Veilus generates a fingerprint that fits the chosen OS, and launching the profile with "Browser Only" opens a window carrying that profile's own fingerprint, cookies and storage.
Network configuration is where the post says most people trip over the setup. In a profile's Network tab, a single profile can be given a manual proxy — HTTP, SOCKS5 or residential — with a Test Proxy button, while many profiles can be handled by building a proxy pool from a list and assigning it. The author states that by default Veilus refuses to launch a profile whose timezone does not match where its proxy exits, on the reasoning that a US IP paired with a Vietnam timezone contradicts itself. With a pool assigned, a "Match to proxy" function measures the proxy's real exit and proposes a matching timezone; with a manual proxy, the user sets the timezone on the Fingerprint tab.
Verification is described as a separate action: ticking a profile and clicking Test opens it on a set of fingerprinting test sites, and a Score column reports how many passed. The post does not name the test sites, does not report any score achieved, and does not describe the scoring methodology, so the result of such a test is not established by this evidence.
The automation portion of the walkthrough is gated. The post states that everything up to this point works on the Free plan, which allows 5 profiles on one device, while automation, schedules and the local API/MCP require a paid plan or a 7-day Pro trial. It points to a plans and license page but does not state prices. To connect an assistant, the user opens API & MCP in the sidebar, turns on a port that the post says listens only on the user's own computer, creates a token, and copies a ready-made snippet for Claude Code, Cursor or Claude Desktop. The post says a Veilus plugin for Claude Code adds skills that walk through the job and stop for the user's decisions.
Natural-language tasking is where the described workflow goes next. Just as they would to a colleague, the user describes the job — opening the first profile, visiting a dashboard login page, writing a script that logs in and prints the account name, and testing it is the post's example. A real profile is opened by the assistant, the page is inspected, a Playwright script is written and saved to Veilus Flow. Trial-running a script on up to 3 profiles while it remains unapproved, with the output read back so the assistant can fix its own errors before the user reviews it, is what the post says is possible; each tool call along the way is said to be shown by an "LLM recipe".
Manual, by design, is how approval works. Under Pending approval in Veilus Flow sits the script, carrying an MCP badge; the user clicks Approve this script after reading the changes or the full source. The rationale is given directly in the post: with the user's profiles and their logins, an approved script runs unattended, and approval takes place in the app, never via the assistant. Should the assistant save a new version later, back to pending it returns, according to the post.
Scheduling is what closes the loop. One path open to the user is asking the assistant to execute the approved script each day at 09:00; alternatively, a schedule can be built inside the Schedule tab, where the choices include a single run, a cron expression, every few minutes, weekly, or daily. Rather than pinning a fixed list, a schedule may aim at a saved filter, which means profiles tagged afterward are pulled in on their own. According to the post, schedules fire only when two conditions hold: Veilus is running, and the computer is awake. Once "Run in background" has been enabled in Settings, moreover, shutting the window does not quit the app — it goes to the tray instead.
Built-in limits are also listed in the post, and among the more concrete operational details in the source they rank. Profiles, proxy pools, scripts or schedules — none of these can be deleted by any tool; deletion remains in the app with the user. Only scripts the user has approved can reach values stored on profiles, such as logins. Counting everything, no more than 16 profile browsers may be open simultaneously, so rather than overloading the machine a large run waits for a free slot.
A different kind of claim comes from the project's GitHub organisation page. A next-generation anti-detect browser with a fully integrated automation platform is how it describes Veilus, built on a "zero-Electron native stack" and written with Rust, Svelte and Cloudflare. 3× faster cold-start and profile switching is asserted, along with roughly 80% less RAM at about 100MB per profile, fingerprints validated by CreepJS and Iphey, and 50+ concurrent profiles on a standard 16GB laptop. A visual automation engine that is low-code/no-code, featuring a node-based designer and JSON-backed execution, zero-knowledge profile synchronisation across devices, and per-profile isolation of fingerprints, cookies, local storage and network configuration are also described.
Those figures and the walkthrough's 16-browser ceiling sit in tension, and the evidence does not resolve it. The GitHub page's "50+ concurrent profiles" is a vendor performance claim; the walkthrough's limit of 16 open profile browsers is a stated product constraint on simultaneous launches. The two may describe different things — total profiles versus browsers open at once — but the supplied text does not say so, and no independent measurement of either figure appears in the evidence. Readers should treat both as vendor statements.
For freelancers, designers and developers who manage multiple accounts or run repetitive browser tasks, the practically relevant part of this material is the shape of the workflow rather than the performance numbers. The described path — isolated profiles with per-profile fingerprints and storage, proxy-to-timezone matching enforced before launch, an assistant that drafts Playwright scripts, a human approval gate before unattended execution, and cron-style scheduling — is a concrete illustration of how AI-assisted browser automation is being packaged. The approval step and the deletion restrictions are the two design choices most likely to matter to anyone considering handing credentials to an automated run.
The tradeoffs are visible in the same text. Automation, scheduling and the local API/MCP sit behind a paid plan or a 7-day trial, and no pricing is given in the evidence. Schedules depend on the machine being awake and the app running, which limits unattended use to a machine that stays on. The 16-browser ceiling caps how much can run in parallel. And the assistant's ability to trial-run unapproved scripts on up to 3 profiles means scripts execute against real profiles before a human has read them, even though stored values such as logins are said to reach only approved scripts.
What remains unknown is substantial. The evidence contains no release date, version number or changelog for Veilus, so this cannot be reported as a new product event. There is no independent verification of the fingerprint-concealment claims, the CreepJS and Iphey validation, the RAM and cold-start figures, or the concurrency numbers. The walkthrough names no fingerprinting test sites and reports no scores. Pricing for the paid tier is referenced but not stated. The post is a vendor-originated community article, and the GitHub page is the project's own repository description; neither is third-party testing.
The reasonable conclusion is that this is a documented onboarding path and a set of vendor claims, not a verified capability report. Developers evaluating anti-detect browsers for multi-account automation can use the walkthrough to understand the intended workflow and its guardrails, but should treat every performance, concurrency and fingerprint claim as unverified until independent testing is available. The most useful next step for a prospective user is to check the linked documentation and plans page for current limits and pricing, since the evidence here does not supply them.