Frequently asked questions

A launcher executable named for the bot (for example BOT_my-bot.exe on Windows). The launcher is a standalone desktop program — no installer, no platform account.

The first launch needs an internet connection to fetch the bot's configuration. After that, behaviour depends on the bot: automations touching websites need connectivity, local file automations do not.

No. The directory has no accounts: downloads and configuration fetches are public endpoints rate limited by IP, and nothing you run requires signing in.

On your machine. The launcher is a desktop program that runs locally; the only network calls it makes are the configuration fetch at launch and whatever pages the bot itself visits.

Yes. Each bot is its own launcher file with its own configuration id, so multiple bots coexist without interfering; run them one at a time unless a bot's page says concurrent runs are safe.

No. The filename carries the bot's configuration id; renaming the file breaks the configuration fetch at launch.

Restore the exact name shown on the bot's download page, extension included, before running it.

The launcher derives its configuration id from its own filename, so a renamed file requests the wrong id and fails closed at the configuration fetch rather than running anything.

At launch it fetches the bot's published configuration from the backend by the id in its filename. The configuration read is public and contains no user data.

Downloads and configuration fetches are rate limited and logged by IP for abuse prevention, as described in the privacy policy.

Yes, for plain-encoded listings: the fetch endpoint is unauthenticated, so anyone who knows the bot's id can read the full configuration. This transparency is documented on the security page, including what it means for password-gated bots.

The launcher fails closed: no configuration, no run. A removed listing answers as unprovisioned and the launcher stops, which is also how a remotely deactivated bot behaves.

Usually not: on the live update channel an already-downloaded launcher receives the newest configuration automatically within the config cache window.

When a bot is pinned to specific versions, or when you move to a machine that has never run the bot.

The bot's page and its changelog tab list every configuration version with its date and notes; the run summary printed at the end of a run states the configuration version the launcher fetched.

Yes: every listing in this directory is priced at zero - no per-run fee, credit meter, or subscription on the bots themselves. The desktop product you would use to author bots is licensed separately, and its tiers include both one-time and subscription billing; the product pricing page is the authoritative source for those prices, and this directory restates none of them.

Yes - building bots to sell as compiled standalone desktop artifacts under your own brand is the intended commercial workflow. Reseller rights are included in the Agency and Enterprise tiers, per the terms published at https://rtila.com; the product's pricing page lists the current tiers and billing models.

On the tiers that grant them (Agency and Enterprise): distributing the compiled artifacts you produce to your own customers under your own brand, per the licence terms at https://rtila.com. They do not cover redistributing the vendor's own binaries or implying endorsement.

No. That is the core of the artifact model: your customer receives an executable, not a workflow they must run on their own platform subscription.

On the product site at https://rtila.com. Pages in this directory describe the model, but the licence terms published there are the authoritative version.

Download the launcher and run the .exe directly - there is no installation or extraction step. SmartScreen may ask about an unrecognised launcher on first run; verify the published SHA-256 digest first, then choose More info and Run anyway.

That message is Gatekeeper's quarantine attribute, not real corruption. Clear it with `xattr -cr BOT_<botId>.sh` in Terminal (after `chmod +x BOT_<botId>.sh`), then run the launcher normally.

Because the artifact is not signed with an Apple Developer ID certificate at this tier. The SHA-256 digest published on the bot's page is the integrity check to use before running it.

The executable bit can be lost in transfer, or by the way your browser or operating system handles a downloaded script, so the launcher may not be executable until you restore it with `chmod +x BOT_<botId>.sh` on macOS and Linux.

Every bot page publishes the SHA-256 checksum and exact byte size of each artifact. On Windows use `Get-FileHash BOT_name.exe -Algorithm SHA256` in PowerShell; on macOS `shasum -a 256`; on Linux `sha256sum`.

The release channel contains exactly four universal launcher binaries, one per platform, with checksums pinned in the published manifest so silent substitution is detectable; a confirmed malicious listing is removed by unpublishing its id.

Automate only what you could do manually, and review each target platform's terms and applicable data-protection law before running a bot against it.

A launcher runs the published configuration and nothing else; it has no installer and writes only its output files beside itself. The real risk surface is what a bot does on websites, which each listing's responsible-use section documents.

Use the takedown page linked from the security page, or email the support address there. Confirmed malicious listings are prioritised and removed by unpublishing the id, which makes every distributed copy fail closed.

Downloads and configuration fetches are logged by IP for abuse prevention and rate limiting, as described in the privacy policy; the launcher does not transmit telemetry about your runs.

Nowhere but your disk. Output files are written beside the launcher on your machine; the directory never receives, stores or processes bot output.

No. The only records kept are the IP-level download and configuration-fetch logs described in the privacy policy, retained for abuse prevention.

Send the compiled artifact file itself, or list it in a directory like this one. The client extracts, verifies the checksum, and runs it - no hosting, no accounts, no platform install on their side.

Yes. The compiled launcher carries your branding, not the vendor's, and white-labelling artifacts you build is an intended use of the reseller rights included in specific licence tiers, per the terms at https://rtila.com.

Yes, when the bot's configuration uses server-controlled activation: updating the stored activation state stops the launcher at its next start, within the published cache window, without touching the client's machine.

A listing can gate execution behind a password prompt at launch. With a plain-encoded configuration the password gates execution only, because the workflow definition stays readable; encryption is what protects the definition too.

Every listing is built from its published project file, run on all declared platforms, and verified against its checksums before publication; the reviewer and date are recorded on the about page.

In-house editorial staff of the company that publishes the directory. Each listing's page names the reviewing team and the review date; the about page describes the checklist the review works through.

Use the takedown page: it explains what to include and commits to a response window. Listings are removed by unpublishing the id from the directory.