Cloud Hosted
Hosted by Automize in AWS eu-west-1 (Dublin) – no infrastructure required from the client. Sign up and start automating.
Everything your IT, security, and architecture teams need to evaluate, deploy, and operate Automize. · Last updated April 2026
Automize bots are distributed as self-contained packaged applications. No programming languages, runtimes, or development tools need to be installed – just download, install, and run.
Download the latest bot release
Installers for Windows, macOS, and Linux – each with a published SHA-256 checksum for your IT team to verify. Browse every version in the full release archive.
Hosted by Automize in AWS eu-west-1 (Dublin) – no infrastructure required from the client. Sign up and start automating.
The web portal can also be deployed on-premises for organisations that require it. Scoped separately and quoted per engagement.
The platform is designed to be always-on. Live status, recovery posture, and incident handling are all customer-visible.
99.9% monthly availability target excluding scheduled maintenance. Specific contractual SLAs available on enterprise plans.
Multi-AZ Amazon RDS for the database, ECS auto-scaling for the application tier, S3 11×9 durability for files. Automatic failover within the EU region.
Real-time platform health at automize.co.za/status – database, cache, storage, and queue connectivity.
Notice periods: 4–6 weeks for major upgrades, 1–2 weeks for routine maintenance, 48–72 hours for critical fixes. Emergency maintenance is communicated immediately.
A stable internet connection of at least 10 Mbps. Everything is outbound over HTTPS/WSS on port 443 – no inbound ports and no site-to-site VPN. Your allowlist has two independent scopes: the machines that run the bot, and the browsers your team uses to reach the portal.
HTTPS and WebSocket Secure on port 443 only. WSS carries live debugging and real-time collaboration.
Exclude automize.co.za from SSL/TLS deep-packet inspection, so a re-signing proxy does not break certificate validation or the WSS upgrade.
Only outbound 443 to the hosts below is required. Automize needs no inbound rules – keep inbound traffic on the bot machine restricted to your own approved ranges.
Authenticated and unauthenticated proxies are supported. Bot ↔ target-system traffic stays inside your network – we never proxy it through our cloud.
Allow outbound HTTPS/WSS (443) from each bot machine to these hosts.
| Destination | Protocol | Purpose |
|---|---|---|
automize.co.za*.automize.co.za |
HTTPS + WSS 443 | Bot ↔ platform control, job dispatch, telemetry, live debugging, and real-time collaboration. |
github.com*.githubusercontent.com |
HTTPS 443 | Download and verify bot installers and updates from the public release archive. Release binaries are served from GitHub asset hosts. |
| Your target systems | Varies | Whatever line-of-business apps, databases, and APIs your automations drive. This traffic never leaves your network. |
The portal is a single-page app that loads a small set of libraries, fonts, and icons from public CDNs. Allow outbound HTTPS (443) from user browsers to these hosts, or the interface will not render correctly.
| Destination | Provider | Purpose |
|---|---|---|
automize.co.za |
Automize | The web portal and its API. |
cdnjs.cloudflare.com |
Cloudflare | JavaScript and CSS libraries (Bootstrap, Chart.js, and others). |
kit.fontawesome.com*.fontawesome.com |
Font Awesome | Interface icons and their webfonts. |
fonts.googleapis.comfonts.gstatic.com |
Google Fonts | Portal typeface. |
*.bootstrapcdn.com |
BootstrapCDN | Bootstrap webfonts. |
*.amazonaws.com |
AWS S3 (eu-west-1) | Your uploaded files, images, and generated PDF previews. |
api.qrserver.com |
QR Server | Renders the QR code shown when enrolling two-factor authentication. |
*.payfast.co.za |
PayFast | Billing and checkout redirect. Only needed if you manage your subscription online. |
*.ingest.sentry.io |
Sentry | Optional client-side error reporting. Safe to omit if your policy blocks it. |
You do not allowlist our upstream services. Integrations such as AI features, email and SMS delivery, single sign-on, and calendar sync run server-side from our AWS eu-west-1 environment. That traffic egresses from our network, not yours, so it needs no rule on your firewall.
The portal at automize.co.za is a standards-based web app. No browser plug-ins required.
Latest two versions of Google Chrome, Microsoft Edge, Mozilla Firefox, Apple Safari, Brave, and Opera. JavaScript and cookies must be enabled.
Same-site cookies for the auth token, plus localStorage for client-side preferences. CSRF tokens on every state-changing request.
Strict-Transport-Security with HSTS preload, Content-Security-Policy with nonced inline scripts, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin.
Full platform support including desktop GUI automation, COM-based Office interaction, and registry access. ARM processors are not supported.
Windows 10 & 11 (64-bit). Windows Server 2016, 2019, 2022, and 2025.
Min: dual-core CPU, 8 GB RAM, 2 GB free disk, 1280×1024 display.
Recommended: quad-core+, 8 GB+ RAM, 5 GB free SSD, 1920×1080.
Microsoft Office 2016+ or LibreOffice 7+. Chrome, Edge, or Firefox. ODBC driver only for database automation. Updated antivirus and firewall.
Run Automize-Windows-Setup.exe. Administrator access required to install; standard user sufficient for daily operation. Windows Defender exclusion is configured automatically.
Native support for both Intel and Apple Silicon (M1, M2, M3, M4).
macOS 13 Ventura, 14 Sonoma, and 15 Sequoia. Intel (x86-64) and Apple Silicon (ARM64).
Min: dual-core i5 or M1, 8 GB RAM, 2 GB free disk, 1280×1024 display.
Recommended: quad-core or M2+, 8 GB+ RAM, 5 GB free, Retina or 1920×1080.
Microsoft Office for Mac 2019+. Chrome, Edge, or Firefox. Updated antivirus and firewall.
Open Automize-macOS-arm64.dmg (Apple Silicon) or Automize-macOS-x64.dmg (Intel). Administrator access required. Grant Accessibility and Automation permissions in System Settings → Privacy & Security.
Desktop GUI automation requires an active display session. File-level Office automation (read, write, convert) is fully supported via LibreOffice.
Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Debian 12 (Bookworm).
Min: dual-core CPU, 8 GB RAM, 2 GB free disk, 1280×1024 display.
Recommended: quad-core+, 8 GB+ RAM, 5 GB free, 1920×1080.
X11 display server (or Xvfb for headless). LibreOffice 7+. Chrome or Firefox. GTK 3 runtime libraries. Updated antivirus and firewall.
Extract Automize-Linux-x64.tar.gz to a location of your choice and run the executable directly – it is a self-contained portable binary with no system installer. Live COM-based Office interaction is unavailable; file-level automation via LibreOffice is fully supported.
Where the bot installs and where it keeps its local data on each operating system. Credentials live in the OS keychain and, together with logs, never leave the machine.
| What | Windows | macOS | Linux |
|---|---|---|---|
| Application | C:\Program Files\Automize\Automize.exe |
/Applications/Automize.app |
<install dir>/Automize |
| Config & data | %LOCALAPPDATA%\Automize\ |
~/Library/Application Support/Automize |
~/.config/Automize, ~/.local/share/Automize |
| Logs | %LOCALAPPDATA%\Automize\ |
~/Library/Logs/Automize |
~/.local/state/Automize/log |
| Cache | %LOCALAPPDATA%\Automize\ |
~/Library/Caches/Automize |
~/.cache/Automize |
| Credentials | Stored in the operating-system keychain (Windows Credential Manager, macOS Keychain, Linux Secret Service) – never in the folders above, and never transmitted off the machine. | ||
Windows installs with administrator rights into C:\Program Files (x86)\Automize – the installer runs in 32-bit mode (no 64-bit install mode is defined), so {autopf} resolves to 32-bit Program Files even on 64-bit Windows. Silent updates and rollbacks re-install into the same directory. App models are kept under the config directory as app-models/*.json.
Antivirus & application allowlisting: security tools that allow or exclude software by executable need the exact binary. The bot runs as Automize.exe on Windows, Automize.app (which wraps Contents/MacOS/Automize) on macOS, and a bare Automize executable on Linux. The Windows installer adds a Microsoft Defender exclusion automatically; any other EDR or application-control policy (for example AppLocker or WDAC) must be configured by your team. For the full exclusion reference – every path, process, and outbound endpoint your AV/EDR team needs – see Bot Antivirus & Firewall Exclusions.
Predictable, controllable update behaviour for change-controlled environments.
Each release publishes a SHA-256 checksum of the installer so your IT team can verify integrity before deploying, plus a full software bill of materials – every bundled dependency and its third-party licence – in the public release archive. Windows Authenticode signing and macOS notarisation are on the roadmap.
The bot checks for new releases and notifies the operator. Updates require explicit consent – nothing is installed silently.
The full release archive is published on GitHub. Enterprises with change-control policies can pin to specific versions and roll forward on their own schedule.
Every release ships with public, version-tagged release notes covering changes, fixes, and known issues.
Automize uses WorkOS as its identity broker, so any SAML 2.0 or OIDC identity provider works out of the box. Social sign-in is available alongside enterprise SSO.
SAML 2.0 and OpenID Connect (OIDC) for enterprise IdPs. OAuth 2.0 authorization-code flow with CSRF state cookie. JWT session tokens.
Microsoft Entra ID (Azure AD), Okta, Google Workspace, OneLogin, Ping Identity, JumpCloud, Auth0, Duo, ADFS, and any custom SAML 2.0 / OIDC provider. Plus social: Google, Microsoft, Apple.
Users are auto-provisioned on first sign-in. Email is auto-validated when the IdP has verified it. Existing users are linked by email to their SSO identity. SCIM directory sync is on the roadmap.
Per-company "SSO required" policy blocks password sign-in once enabled. MFA enforced at your IdP applies automatically – we honour TOTP, push, hardware keys, and conditional access.
Configurable controls so your security team can match Automize to your existing access policies.
TOTP-based 2FA for password accounts. Workspace admins can require 2FA for everyone signing in with a password.
Short-lived JWT session tokens. Idle and absolute timeouts; admins can sign users out remotely. Sign-in attempts are rate-limited per IP.
Hashed with industry-standard adaptive hashing. Minimum length and complexity enforced; common-password rejection. Customers should prefer SSO and enforce it on the workspace.
Workspace-level IP allowlisting available on enterprise plans – restrict portal sign-in to your office or VPN ranges. Contact us to enable.
Credentials for the systems your bots automate stay on the customer’s machine. They never reach the Automize cloud and are never visible to Automize personnel.
Each bot stores credentials in an AES-256 encrypted vault on the workstation, VM, or VDI it runs on.
Credentials are not transmitted to the Automize cloud, replicated, or backed up off-machine. The same boundary protects screen contents and on-machine files.
You add, rotate, and revoke credentials directly in the bot. Disabling the underlying service account stops bot access instantly – no Automize action required.
Username + password, API keys, certificates, OAuth tokens, and TOTP/app-based MFA secrets. Hardware-key MFA (YubiKey, FIDO2) cannot be automated – use a service-account exemption.
Bots inherit the access of the account they run as. Use dedicated service accounts scoped to least privilege per process.
A dedicated AD or directory account per bot (or per process). Assign the minimum permissions the process needs – nothing more.
The bot machine itself joins the VPN. Bot ↔ target-system traffic stays inside your network – we never proxy it.
For Outlook automation, provision a dedicated mailbox (e.g. automation@yourdomain.com) with desktop Outlook installed and signed in.
Read/write permissions on the directories the bot needs – OneDrive, Google Drive, SMB shares, or local paths.
Granular, object-level access control. Permissions can be granted to individual users, teams, or external collaborators – on any object in the workspace.
Permissions live on the object – processes, bots, folders, dashboards, kanbans, wikis. Not just on a global role.
Four levels – view, edit, manage, admin. Inherited from parent folders by default; overridable per object.
Group users into teams; share once, apply to many. Share with named users for fine-grained collaboration; revoke instantly.
Every customer is a separate workspace. Cross-workspace data access is impossible by design – enforced at the database, IAM, and bucket-policy levels.
Strong encryption at every layer, EU-resident at rest, with workspace isolation enforced top-to-bottom.
HTTPS-only between bots, the web portal, and the Automize cloud. HSTS preload on the public domain. WSS for WebSocket traffic.
AWS SSE-S3 for files, AWS-managed encryption for the database, AES-256 throughout. Keys managed by AWS KMS.
All customer data hosted in AWS eu-west-1 (Dublin). No cross-region replication. Sub-processor list and DPA available on the Trust Center.
The database lives in a private subnet with no public network path. AWS IAM and bucket policies enforce service-level isolation.
Keep antivirus current on bot machines. Add an exclusion for the Automize install directory if it interferes with bot execution.
Time-stamped trails for every workflow run and every administrative action – available for compliance review and exportable to your SIEM.
Every action of every bot run is logged with input parameters, output values, timestamps (UTC), and exception traces.
Sensitive admin actions (sign-ins, permission changes, exports) are logged to a separate audit table with 30-day retention.
Stream audit and bot-run events to Splunk, Datadog, Elastic, S3, or any HTTPS endpoint via outbound webhooks. The REST API also supports pulled exports.
Last-ping timestamps, online/away/offline status, automatic alerts on failures, and per-bot run histories on the dashboard.
Who at Automize can see customer data, when, and under what controls.
Automize personnel do not access customer process data, files, credentials, or screen contents in the course of normal operations.
Production access is time-bound, requires manager approval, MFA, and is granted only for an investigation, support ticket, or operational incident. Revoked when the task ends.
All privileged actions are logged to the endpoint audit trail. Admin sign-ins, exports, and permission changes are immutably recorded.
Staff with access to production are bound by written confidentiality agreements. Background screening for engineers granted production access; quarterly access reviews.
Security is built into how we ship code. Automated scanning runs continuously; independent testing on a regular cadence.
Dependabot continuously monitors third-party libraries for known vulnerabilities and proposes upgrade pull requests automatically.
Every container image is scanned with Trivy in CI before deployment. Builds fail on critical CVEs in our image layer.
The application passes PHPStan level 10 with zero errors on every commit – strict typing and dead-code detection enforced in CI.
Annual third-party penetration testing planned for the SOC 2 audit cycle. Executive summaries available under NDA on request.
Found a security issue? Email security@automize.co.za. We acknowledge reports within two business days.
Aligned to the standards your IT, legal, and procurement teams ask about.
Compliant with the EU/UK General Data Protection Regulation and South Africa’s Protection of Personal Information Act.
Readiness assessment in progress. Controls, scanning, and access reviews already in place.
Incident-management process aligned to ISO/IEC 27035:2016. ISO 27001 certification is on the roadmap.
For our own subscription billing we hold PCI-DSS SAQ-A (April 2026 self-attestation; PayFast hosted-redirect, card data never touches our servers). The platform is not currently designed to store customer PHI or customer cardholder data as process variables. Talk to us at privacy@automize.co.za if you have specific regulated-data requirements.
72-hour breach notification per GDPR Article 33. Sub-processor list and DPA on the Trust Center; 30-day advance notice before any new sub-processor is added.
Continuous backups, point-in-time recovery, and a documented recovery posture – encrypted and EU-resident throughout.
AWS RDS automated backups: daily snapshots plus continuous transaction-log capture. Encrypted with AWS KMS and stored in the same EU region as the live database.
Restore the database to any second within the snapshot window. RPO ≤ 5 minutes; target RTO ≤ 4 hours for region-wide events.
Database deployed Multi-AZ in eu-west-1 with automatic failover. Application tier auto-scales across availability zones.
Restore-from-snapshot procedures are exercised and documented as part of the SOC 2 readiness programme. DR runbooks are version-controlled.
Predictable retention windows and clear export and deletion paths – aligned to GDPR Articles 15, 17, and 20.
Retained for the duration of your subscription. Application and audit logs retained 30 days.
Self-service exports of processes, runs, and reports via the portal and API. Full account export available for 30 days after termination on request.
Live data is deleted within 30 days of contract termination. Backups expire within a further 35 days. Certificate of destruction available on request.
Data-subject access, rectification, and erasure requests fulfilled within statutory windows. Email privacy@automize.co.za.
Programmatic access for integrations, custom dashboards, and orchestration with your existing tooling.
Versioned REST API at /api/v1/. Bearer-token authentication. JSON request/response with consistent error envelopes and machine-readable error codes.
HMAC-SHA256 signatures over <timestamp>.<body> with a per-webhook secret. Stripe-style X-Automize-Signature header. Configurable retries with exponential back-off; dead-letter after 3 attempts. Verification snippets ↓
Fair-use throttling per IP and per token. 429 Too Many Requests with Retry-After and X-RateLimit-Remaining headers.
Major API versions are stable. Breaking changes ship a new version; the previous version is supported for at least 12 months. Deprecation notices on every retiring endpoint.
Every webhook delivery carries two headers you can use to authenticate the payload:
X-Automize-Signature: t=<unix>,v1=<hmac> – Stripe-style; the part after v1= is HMAC-SHA256 of <unix>.<raw-body> with your webhook’s secret.X-Automize-Timestamp: <unix> – the same timestamp, surfaced separately for convenience.Recommended verification: recompute the HMAC, compare with constant-time equality, and reject any delivery whose timestamp is older than 5 minutes – this defends against replay of intercepted requests.
Verify against the raw request body, not a re-serialised JSON object – whitespace and key ordering matter.
$body = file_get_contents('php://input');
$sig = $_SERVER['HTTP_X_AUTOMIZE_SIGNATURE'] ?? '';
$ts = (int) ($_SERVER['HTTP_X_AUTOMIZE_TIMESTAMP'] ?? 0);
if (abs(time() - $ts) > 300) {
http_response_code(401); exit; // replay defence
}
preg_match('/^t=(\d+),v1=([0-9a-f]{64})$/', $sig, $m) or exit(401);
$expected = hash_hmac('sha256', $m[1].'.'.$body, $WEBHOOK_SECRET);
if (!hash_equals($expected, $m[2])) {
http_response_code(401); exit;
}
// ... process $body
const crypto = require('crypto');
app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
const sig = req.header('X-Automize-Signature') || '';
const ts = parseInt(req.header('X-Automize-Timestamp') || '0', 10);
if (Math.abs(Date.now() / 1000 - ts) > 300) return res.sendStatus(401);
const m = sig.match(/^t=(\d+),v1=([0-9a-f]{64})$/);
if (!m) return res.sendStatus(401);
const expected = crypto
.createHmac('sha256', WEBHOOK_SECRET)
.update(m[1] + '.' + req.body)
.digest('hex');
const sigBuf = Buffer.from(m[2], 'hex');
const expBuf = Buffer.from(expected, 'hex');
if (sigBuf.length !== expBuf.length || !crypto.timingSafeEqual(sigBuf, expBuf)) {
return res.sendStatus(401);
}
// ... process JSON.parse(req.body.toString())
});
import hmac, hashlib, time, re
from flask import Flask, request, abort
@app.route('/webhook', methods=['POST'])
def webhook():
sig = request.headers.get('X-Automize-Signature', '')
ts = int(request.headers.get('X-Automize-Timestamp', '0'))
if abs(time.time() - ts) > 300:
abort(401) # replay defence
m = re.match(r'^t=(\d+),v1=([0-9a-f]{64})$', sig)
if not m:
abort(401)
expected = hmac.new(
WEBHOOK_SECRET.encode(),
f"{m.group(1)}.{request.get_data(as_text=True)}".encode(),
hashlib.sha256,
).hexdigest()
if not hmac.compare_digest(expected, m.group(2)):
abort(401)
# ... process request.json
Controls for the moment a bot actually touches data – what gets captured, what gets masked, and what stays local.
Password and credential fields are masked in run logs and on-screen prompts. Vault entries never render in plain text.
Step-level screenshots are off by default. Enable per-process for debugging; turn off for production. Screenshots that are uploaded follow the standard workspace data path.
Variables can be marked secret – values are write-only after creation, redacted in logs, and not exposed to the API.
Bots read your data on your machine. Only the outputs you configure – status, summary metrics, opt-in artefacts – reach the platform.
How a process moves from build to production with traceability and approval – and how changes are tracked thereafter.
Every process keeps a full edit history with author and timestamp. Roll back to any prior version with one click.
Build and validate against a sandbox/test environment before promoting to production. Process owners sign off via the portal; sign-off is recorded in the audit log.
Post-go-live changes use a documented change-request workflow: submit, review, approve, deploy, validate. Routine enhancements typically turn around in 2 business days.
Notify us in advance of UI or workflow changes to systems your bots automate – the single biggest cause of bot breakage. We adjust proactively to prevent downtime.
The same OS-specific requirements apply. Allocate additional resources for VM overhead. Ensure a display session is configured (even for headless VMs) as GUI automation requires an active screen.
VMware Workstation and ESXi.
Microsoft Hyper-V and Azure Virtual Desktop.
Oracle VirtualBox, Citrix Virtual Apps and Desktops, AWS EC2 and WorkSpaces.
Each concurrent bot instance requires its own dedicated resources. Scale linearly based on the number of simultaneous processes.
Add two CPU cores per additional concurrent bot session.
Add four gigabytes of RAM per additional concurrent bot session.
Typical bot throughput is 100–500 transactions per hour, gated by target-system response times. Queues distribute work across multiple bots; throughput scales linearly with the bot fleet.
| Concurrent Bots | CPU Cores | RAM | Disk Space |
|---|---|---|---|
| 1 | 2 (4 recommended) | 8 GB | 5 GB SSD |
| 2 | 4 (6 recommended) | 12 GB | 7 GB SSD |
| 4 | 8 (12 recommended) | 20 GB | 11 GB SSD |
| 8 | 16 (20 recommended) | 36 GB | 19 GB SSD |
Environment-level prerequisites and the catalogue of pre-built connectors – only required if your automations use the corresponding features.
Identity (Okta, Microsoft Entra ID), data, AI, storage, DevOps, finance, and SaaS – Salesforce, SAP, Stripe, Slack, AWS, Azure, and more. Browse the full list →
Excel, Word, Outlook, and PowerPoint desktop apps for Office automation. Use a dedicated bot mailbox for Outlook (not the web version).
The appropriate ODBC driver for your database – SQL Server, MySQL, PostgreSQL, Oracle, or other.
Required only if you use custom Python plugins. Install Python 3.10+ and any libraries your plugin code depends on.
Access credentials and/or API keys for third-party platforms such as Sage, Xero, or SAP.
Read/write permissions on designated directories – OneDrive, Google Drive, or network file shares.
Only required for on-device optical character recognition. Cloud OCR requires no additional software.
No additional software required. All AI requests are processed via the Automize cloud service.
Each connector requires you to supply the matching access details – API keys, OAuth tokens, service-account credentials, tenant IDs, or endpoint URLs. They’re stored in the bot’s local encrypted vault (see Credentials & System Access).
Time-zone handling for global teams; UI translation for international rollouts.
Timestamps stored in UTC. Run logs, audit logs, and API responses use ISO 8601 with explicit UTC offsets.
Per-user display time zone in the portal. Schedules and triggers can be configured in any IANA time zone, including DST handling.
UI translatable into multiple languages via the same data-i18n framework used across this site. Default English; additional languages on request.
Universal pre-requisites – applies to every customer, whether you build your own bots or have us build them for you. Most engagements complete this in a single kick-off call.
Allow automize.co.za on outbound HTTPS/443 and exclude it from SSL inspection.
One workstation, VM, or VDI per concurrent process – sized per the Scaling table above.
Connect your SAML/OIDC IdP via WorkOS. Enforce SSO on the workspace once verified.
Dedicated AD/service account per bot, scoped to least privilege. VPN access on the bot machine if internal systems are in scope.
Per system in scope: API keys or passwords, OAuth tokens, database credentials with read/write where needed, and schema details for the relevant tables.
Sign the Data Processing Agreement before any personal data is processed. Confirm what data classes the bot will handle – PII, financial, health – so logging and retention can be configured accordingly.
Additional access we’ll need only when Automize is implementing the automation for you. None of this applies to self-service customers building their own bots.
Temporary VPN access for our build team to reach the systems your process touches. The same VPN your staff use is fine – we work inside your network boundary, not ours. Access is revoked at handover.
Sign-in to each system the process touches, ideally as a build-only test account. We use this to record screens, configure selectors, and validate – not to move real data.
A staging or non-prod instance of the target systems with representative sample data. We build, record, and validate here before promoting to production.
A live session with someone who knows the process end-to-end. We watch you do it once, ask questions, and build from there. You do not need a written SOP – we capture the procedure as we go.
One technical contact and one process owner on your side. They review during build, sign off on UAT, and approve go-live.
Need help with setup or have questions about compatibility? Our support team is here for you.
Monday to Friday, 8:00 AM – 5:00 PM SAST.
Real-time platform health at automize.co.za/status.
340+ help articles with step-by-step guides, available directly inside the platform.