Repository: trailofbits/algo

Stars: 30249

CLAUDE.md Copy Chapter

CLAUDE.md - LLM Guidance for Algo VPN

This document provides essential context and guidance for LLMs working on the Algo VPN codebase.

Project Overview Copy Chapter

Algo is an Ansible-based tool that sets up a personal VPN in the cloud. It's designed to be:
- Security-focused: Creates hardened VPN servers with minimal attack surface
- Easy to use: Automated deployment with sensible defaults
- Multi-platform: Supports various cloud providers and operating systems
- Privacy-preserving: No logging, minimal data retention

Core Technologies Copy Section

Philosophy Copy Section

Architecture and Structure Copy Chapter

algo/
├── main.yml                 # Primary playbook
├── users.yml               # User management playbook
├── server.yml              # Server-specific tasks
├── config.cfg              # Main configuration file
├── pyproject.toml          # Python project configuration and dependencies
├── uv.lock                 # Exact dependency versions lockfile
├── requirements.yml        # Ansible collections
├── roles/                  # Ansible roles
│   ├── common/            # Base system configuration, firewall, hardening
│   ├── wireguard/         # WireGuard VPN setup
│   ├── strongswan/        # IPsec/IKEv2 setup
│   ├── dns/               # DNS configuration (dnscrypt-proxy)
│   └── cloud-*/           # Cloud provider specific roles
├── library/               # Custom Ansible modules
└── tests/unit/            # Python unit tests

Development Workflow Copy Chapter

Quality Gates (MANDATORY) Copy Section

All PRs must pass these checks locally before submission. CI will reject failures:

Run the full lint suite (same as CI)

ansible-lint . && yamllint . && ruff check . && shellcheck scripts/*.sh && semgrep --config auto --exclude-rule dockerfile.security.last-user-is-root.last-user-is-root --error --quiet .
ansible-playbook main.yml --syntax-check
ansible-playbook users.yml --syntax-check
pytest tests/unit/ -q

Common lint issues to fix before submitting:
- YAML files missing --- document start markers
- GitHub workflows with unquoted on: (must be 'on':)
- Using ignore_errors: true instead of failed_when: false
- Jinja2 spacing errors ({{foo}} should be {{ foo }})
- Missing mode: on file/directory tasks

Zero-Tolerance Warning Policy Copy Section

No warnings are tolerated in CI. Every linter finding must be either fixed or explicitly allowlisted in the tool's config file (.ansible-lint, pyproject.toml, etc.).

Why this matters for Algo:
- Security tool - VPN misconfigurations silently break privacy guarantees. A "cosmetic" warning today hides a real bug tomorrow.
- Ansible complexity - YAML+Jinja2 linting catches real runtime failures (wrong key order breaks when evaluation, spacing errors cause template failures). Warnings in Ansible are not style nits.
- CI signal integrity - If 30 warnings scroll by on every run, the 31st one (a real regression) goes unnoticed. Zero warnings means every new finding gets human attention.

Resolution order of preference:
1. Fix it - Preferred. Most findings have straightforward fixes.
2. Allowlist in config - If the rule is wrong for this project, add to skip_list with a comment explaining why.
3. Inline suppress - Last resort. Use # noqa: rule-name with a comment justifying the exception.

Never use warn_list in .ansible-lint — it exists as a migration tool, not a permanent home. Rules either pass or are explicitly skipped.

Design Requirements Copy Section

When adding or modifying features, verify these before requesting review:

1. Validate inputs early - Check for empty lists, missing configs, permission mismatches before expensive operations
2. Explicit file modes - Always specify mode: on file/directory tasks (never rely on umask)
3. Fail vs warn - Permission/security issues should fail; optional features can warn
4. Actionable errors - Include fix commands in error messages: "Run: sudo chown -R $USER configs/"
5. Follow existing patterns - Search codebase first: rg "when:.*localhost" --type yaml

Linting Tools Copy Section

| Tool | Target | Key Rules |
|------|--------|-----------|
| ansible-lint | YAML tasks | Use failed_when not ignore_errors, add mode: to files |
| yamllint | All YAML | Document start ---, quote 'on': in workflows |
| ruff | Python | Line length 120, target Python 3.11 |
| shellcheck | Shell scripts | Quote variables, use set -euo pipefail |
| semgrep | All code | SAST scanner, --config auto, suppress with # nosemgrep: rule-id |

Git Workflow Copy Section

1. Create feature branches from master
2. Run all linters before pushing
3. Make atomic commits with clear messages
4. Update PR description with test results

Self-Review Checklist Copy Section

Before creating a PR, review your own diff:

- [ ] Did I run all linters locally?
- [ ] Did I search for similar patterns in the codebase?
- [ ] Did I add explicit mode: to file/directory tasks?
- [ ] Did I validate inputs before expensive operations?
- [ ] Did I update tests if I changed file paths or behavior?
- [ ] Would a reviewer ask "what happens if X is empty/missing?"

Ansible Pitfalls Copy Chapter

with_items vs loop Copy Section

with_items auto-flattens lists; loop does not. Never mechanically convert:

WRONG - treats list as single item, creates file named "['alice', 'bob']"

loop:
  - "{{ users }}"
CORRECT - iterates over list contents

loop: "{{ users }}"
CORRECT - combining lists (with_items did this automatically)

loop: "{{ users + [server_name] }}"

Always test loop conversions - verify the task creates expected files.

Path Variables Copy Section

Never include trailing slashes - causes double-slash bugs:

WRONG - creates paths like /etc/ipsec.d//private

ipsec_path: "configs/{{ server }}/ipsec/"
CORRECT

ipsec_path: "configs/{{ server }}/ipsec"

ignore_errors vs failed_when Copy Section

WRONG - ansible-lint failure

- name: Clear history
  command: some_command
  ignore_errors: true
CORRECT - explicit about expected failures

- name: Clear history
  command: some_command
  failed_when: false

changed_when on Read-Only Tasks Copy Section

Handlers and check commands that don't modify state need changed_when: false:

- name: Check service status
  command: systemctl status foo
  changed_when: false

Jinja2 Native Mode (Ansible 12+) Copy Section

Ansible 12 enables jinja2_native by default, changing how values are evaluated:

Boolean conditionals require actual booleans:

WRONG - string "true" is not boolean

ipv6_support: "{% if ipv6 %}true{% else %}false{% endif %}"
CORRECT - return actual boolean

ipv6_support: "{{ ipv6 is defined }}"

No nested templates in lookup():

WRONG - deprecated double-templating

key: "{{ lookup('file', '{{ SSH_keys.public }}') }}"
CORRECT - pass variable directly

key: "{{ lookup('file', SSH_keys.public) }}"

JSON files need explicit parsing:

WRONG - returns string in native mode

creds: "{{ lookup('file', 'credentials.json') }}"
CORRECT - parse JSON explicitly

creds: "{{ lookup('file', 'credentials.json') | from_json }}"

default() doesn't trigger on empty strings:

WRONG - empty string '' is not undefined

key: "{{ lookup('env', 'AWS_KEY') | default('fallback') }}"
CORRECT - add true to handle falsy values

key: "{{ lookup('env', 'AWS_KEY') | default('fallback', true) }}"

Complex Jinja loops break in set_fact:

WRONG - list comprehension fails in native mode

servers: "[{% for s in configs %}{{ s.name }},{% endfor %}]"
CORRECT - use Ansible loop

servers: "{{ servers | default([]) + [item.name] }}"
loop: "{{ configs }}"

Use tests (not filters) for boolean checks:

WRONG - filters return transformed data, not booleans

that: my_ip | ansible.utils.ipv4
CORRECT - tests return native booleans

that: my_ip is ansible.utils.ipv4_address

DNS Architecture Copy Chapter

Algo uses a randomly generated IP in 172.16.0.0/12 on the loopback interface (local_service_ip) for DNS. This provides consistency across WireGuard and IPsec but requires understanding systemd socket activation.

Why This Design Copy Section

- Consistent DNS IP across both VPN protocols
- Survives interface changes and restarts
- Works identically across all cloud providers
- Trade-off: Requires route_localnet=1 sysctl

systemd Socket Activation Copy Section

Ubuntu's dnscrypt-proxy uses socket activation which completely ignores the listen_addresses config setting. You must configure the socket, not the service:

/etc/systemd/system/dnscrypt-proxy.socket.d/10-algo-override.conf

[Socket]
ListenStream=              # Clear defaults first
ListenDatagram=
ListenStream=172.x.x.x:53  # Then set VPN IP
ListenDatagram=172.x.x.x:53

Common mistakes:
- Trying to disable/mask the socket (breaks service dependency)
- Only setting ListenStream (need ListenDatagram for UDP)
- Forgetting to restart socket after config changes

Debugging DNS Copy Section

Many "routing" issues are actually DNS issues. Start here:

ss -lnup | grep :53                      # Should show local_service_ip:53
systemctl status dnscrypt-proxy.socket   # Check for config warnings
sysctl net.ipv4.conf.all.route_localnet  # Must be 1
dig @172.x.x.x google.com                # Test resolution

For comprehensive diagnostics, see docs/troubleshooting.md.

Common Issues Copy Chapter

iptables Backend (nft vs legacy) Copy Section

Ubuntu 22.04+ defaults to iptables-nft which reorders rules unpredictably. Algo forces iptables-legacy for consistent behavior. Switching backends can break DNS routing that previously worked.

Multi-homed Systems (DigitalOcean, etc.) Copy Section

Servers with both public and private IPs on the same interface need explicit output interface for NAT:

-o {{ ansible_default_ipv4['interface'] }}

Don't overengineer with SNAT - MASQUERADE with interface specification works fine.

OpenSSL Version Compatibility Copy Section

OpenSSL 3.x dropped support for legacy algorithms. Add -legacy flag conditionally:

{{ (openssl_version is version('3', '>=')) | ternary('-legacy', '') }}

IPv6 Endpoint Formatting Copy Section

WireGuard configs must bracket IPv6 addresses:

{% if ':' in IP %}[{{ IP }}]:{{ port }}{% else %}{{ IP }}:{{ port }}{% endif %}

Jinja2 Templates Copy Section

Many templates use Ansible-specific filters. Test with tests/unit/test_template_rendering.py and mock Ansible filters when testing.

Time Wasters to Avoid Copy Chapter

Lessons learned - don't spend time on these unless absolutely necessary:

1. Converting MASQUERADE to SNAT - MASQUERADE works fine for Algo's use case
2. Fighting systemd socket activation - Configure it properly instead of disabling
3. Debugging NAT before checking DNS - Most "routing" issues are DNS issues
4. Complex IPsec policy matching - Keep NAT rules simple
5. Testing on existing servers - Always test on fresh deployments
6. Interface-specific route_localnet - WireGuard interface doesn't exist until service starts
7. DNAT for loopback addresses - Packets to local IPs don't traverse PREROUTING

What to Avoid Copy Chapter

- Speculative features - Don't add "might be useful" functionality. Open an issue instead.
- New dependencies without justification - Vanilla Ansible/Python can do most things.
- Bundling unrelated fixes - One PR, one purpose. Separate issues get separate PRs.
- Assuming behavior - If converting with_items to loop, test that it still works. If adding a firewall rule, verify packets flow.
- Configuration options - Don't add flags unless users actively need them. Each option doubles testing surface.
- Undocumented workarounds - When working around broken upstream modules, file an issue and add a comment linking to it. Future maintainers need to know why workarounds exist.

Writing Effective Tests Copy Chapter

When writing tests, verify your test actually detects the failure case (mutation testing approach):

1. Write the test for the bug you're preventing
2. Temporarily introduce the bug to verify the test fails
3. Fix the bug and verify the test passes
4. Document what specific issue the test prevents

def test_regression_openssl_inline_comments():
    """Tests that we detect inline comments in Jinja2 expressions."""
    # This pattern SHOULD fail (has inline comments)
    problematic = "{{ ['DNS:' + id,  # comment ] }}"
    assert not validate(problematic), "Should detect inline comments"
    # This pattern SHOULD pass (no inline comments)
    fixed = "{{ ['DNS:' + id] }}"
    assert validate(fixed), "Should pass without comments"

Quick Reference Copy Chapter

Local Development Setup Copy Section

uv sync
uv run ansible-galaxy install -r requirements.yml
ansible-playbook main.yml -e "provider=local"

Common Commands Copy Section

Add/update users

ansible-playbook users.yml -e "server=SERVER_NAME"
Update dependencies

uv lock && pytest tests/unit/ -q
Debug deployment

ansible-playbook main.yml -vvv

Key Directories Copy Section

- configs/ - Generated client configurations
- roles/*/tasks/ - Main task files
- roles/*/templates/ - Jinja2 templates
- library/ - Custom Ansible modules (add to mock_modules in .ansible-lint)

Non-Interactive Deployment Copy Chapter

All pause: prompts in input.yml and provider roles skip when their
variable is pre-defined via -e or environment variables. This enables
fully headless deployment for CI, agents, and scripted workflows.
See docs/deploy-from-ansible.md for
full human-facing documentation.

Core variables Copy Section

These bypass the main prompts in input.yml:

| Variable | Type | Default | Purpose |
|----------|------|---------|---------|
| provider | string | (prompt) | Provider alias (e.g., digitalocean, ec2, local) |
| server_name | string | algo | VPN server name |
| ondemand_cellular | bool | false | iOS/macOS Connect On Demand for cellular |
| ondemand_wifi | bool | false | iOS/macOS Connect On Demand for Wi-Fi |
| ondemand_wifi_exclude | string | (none) | Comma-separated trusted Wi-Fi networks |
| store_pki | bool | false | Retain PKI keys (needed to add users later) |
| dns_adblocking | bool | false | Enable DNS ad blocking |
| ssh_tunneling | bool | false | Per-user SSH tunnel accounts |

Provider credentials Copy Section

| Provider | -e variables | Env var fallbacks |
|----------|---------------|-------------------|
| digitalocean | do_token, region | DO_API_TOKEN |
| ec2 | aws_access_key, aws_secret_key, region | AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY (also reads ~/.aws/credentials) |
| lightsail | aws_access_key, aws_secret_key, region | AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY |
| azure | azure_secret, azure_tenant, azure_client_id, azure_subscription_id, region | AZURE_SECRET, AZURE_TENANT, AZURE_CLIENT_ID, AZURE_SUBSCRIPTION_ID |
| gce | gce_credentials_file, region | GCE_CREDENTIALS_FILE_PATH |
| hetzner | hcloud_token, region | HCLOUD_TOKEN |
| vultr | vultr_config, region | VULTR_API_CONFIG |
| scaleway | scaleway_token, scaleway_org_id, region | SCW_TOKEN, SCW_DEFAULT_ORGANIZATION_ID |
| linode | linode_token, region | LINODE_API_TOKEN |
| cloudstack | cs_key, cs_secret, cs_url, region | CLOUDSTACK_KEY, CLOUDSTACK_SECRET, CLOUDSTACK_ENDPOINT |
| openstack | region | OS_AUTH_URL (source your openrc.sh) |
| local | server, endpoint, local_install_confirmed | (none) |

Minimal examples Copy Section

DigitalOcean — fully headless

ansible-playbook main.yml -e \
  "provider=digitalocean
   server_name=algo
   region=nyc3
   do_token=YOUR_TOKEN
   ondemand_cellular=false
   ondemand_wifi=false
   dns_adblocking=false
   ssh_tunneling=false
   store_pki=false"
Local — for CI/testing

ansible-playbook main.yml -e \
  "provider=local
   server=localhost
   endpoint=10.0.0.1
   local_install_confirmed=true
   ondemand_cellular=false
   ondemand_wifi=false
   dns_adblocking=false
   ssh_tunneling=false"

Updating users non-interactively Copy Section

ansible-playbook users.yml -e "server=YOUR_SERVER ca_password=YOUR_CA_PASS"

The server variable bypasses the server selection prompt.
ca_password is only required when IPsec is enabled.

Security Considerations Copy Chapter

- Never expose secrets - No passwords/keys in commits
- CVE Response - Update immediately when security issues found
- Least Privilege - Minimal permissions, dropped capabilities
- Secure Defaults - Strong crypto (secp384r1), no logging, strict firewall

Platform Support Copy Chapter

- Primary OS: Ubuntu 22.04/24.04 LTS
- Secondary: Debian 11/12
- Architectures: x86_64 and ARM64
- Testing tip: DigitalOcean droplets have both public and private IPs on eth0, making them good test cases for multi-IP NAT scenarios

README.md Copy Chapter

Algo VPN


Algo VPN is a set of Ansible scripts that simplify the setup of a personal WireGuard and IPsec VPN. It uses the most secure defaults available and works with common cloud providers.

See our release announcement for more information.

Features Copy Chapter

* Supports only IKEv2 with strong crypto (AES-GCM, SHA2, and P-256) for iOS, MacOS, and Linux
* Supports WireGuard for all of the above, in addition to Android and Windows 11
* Generates .conf files and QR codes for iOS, macOS, Android, and Windows WireGuard clients
* Generates Apple profiles to auto-configure iOS and macOS devices for IPsec - no client software required
* Includes helper scripts to add, remove, and manage users
* Blocks ads with a local DNS resolver (optional)
* Sets up limited SSH users for tunneling traffic (optional)
* Privacy-focused with minimal logging, automatic log rotation, and configurable privacy enhancements
* Based on Ubuntu 22.04 LTS with automatic security updates
* Installs to DigitalOcean, Amazon Lightsail, Amazon EC2, Vultr, Microsoft Azure, Google Compute Engine, Scaleway, OpenStack, CloudStack, Hetzner Cloud, Linode, or your own Ubuntu server (for advanced users)

Anti-features Copy Chapter

* Does not support legacy cipher suites or protocols like L2TP, IKEv1, or RSA
* Does not install Tor, OpenVPN, or other risky servers
* Does not depend on the security of TLS
* Does not claim to provide anonymity or censorship avoidance
* Does not claim to protect you from the FSB, MSS), DGSE, or FSM

Deploy the Algo Server Copy Chapter

The easiest way to get an Algo server running is to run it on your local system or from Google Cloud Shell and let it set up a _new_ virtual machine in the cloud for you.

1. Setup an account on a cloud hosting provider. Algo supports DigitalOcean (most user friendly), Amazon Lightsail, Amazon EC2, Vultr, Microsoft Azure, Google Compute Engine, Scaleway, DreamCompute, Linode, other OpenStack-based cloud hosting, CloudStack-based cloud hosting, or Hetzner Cloud.

2. Get a copy of Algo. The Algo scripts will be run from your local system. There are two ways to get a copy:

- Download the ZIP file. Unzip the file to create a directory named algo-master containing the Algo scripts.

- Use git clone to create a directory named algo containing the Algo scripts:

git clone https://github.com/trailofbits/algo.git

3. Set your configuration options. Open config.cfg in your favorite text editor. Specify the users you want to create in the users list. Create a unique user for each device you plan to connect to your VPN. You should also review the other options before deployment, as changing your mind about them later may require you to deploy a brand new server.

4. Start the deployment. Return to your terminal. In the Algo directory, run the appropriate script for your platform:

macOS/Linux:

./algo

Windows:

.\algo.ps1

The first time you run the script, it will automatically install the required Python environment (Python 3.11+). On subsequent runs, it starts immediately and works on all platforms (macOS, Linux, Windows via WSL). The Windows PowerShell script automatically uses WSL when needed, since Ansible requires a Unix-like environment. There are several optional features available, none of which are required for a fully functional VPN server. These optional features are described in the deployment documentation.

That's it! You can now set up clients to connect to your VPN. Proceed to Configure the VPN Clients below.

"#                          Congratulations!                            #"
    "#                     Your Algo server is running.                     #"
    "#    Config files and certificates are in the ./configs/ directory.    #"
    "#              Go to https://whoer.net/ after connecting               #"
    "#        and ensure that all your traffic passes through the VPN.      #"
    "#                     Local DNS resolver 172.16.0.1                    #"
    "#        The p12 and SSH keys password for new users is XXXXXXXX       #"
    "#        The CA key password is XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX       #"
    "#      Shell access: ssh -F configs/<server_ip>/ssh_config <hostname>  #"

Configure the VPN Clients Copy Chapter

Certificates and configuration files that users will need are placed in the configs directory. Make sure to secure these files since many contain private keys. All files are saved under a subdirectory named with the IP address of your new Algo VPN server.

Important for IPsec users: If you want to add or delete users later, you must select yes at the Do you want to retain the keys (PKI)? prompt during the server deployment. This preserves the certificate authority needed for user management.

Apple Copy Section

WireGuard is used to provide VPN services on Apple devices. Algo generates a WireGuard configuration file, wireguard/<username>.conf, and a QR code, wireguard/<username>.png, for each user defined in config.cfg.

On iOS, install the WireGuard app from the iOS App Store. Then, use the WireGuard app to scan the QR code or AirDrop the configuration file to the device.

On macOS, install the WireGuard app from the Mac App Store. WireGuard will appear in the menu bar once you run the app. Click on the WireGuard icon, choose Import tunnel(s) from file..., then select the appropriate WireGuard configuration file.

On either iOS or macOS, you can enable "Connect on Demand" and/or exclude certain trusted Wi-Fi networks (such as your home or work) by editing the tunnel configuration in the WireGuard app. (Algo can't do this automatically for you.)

If you prefer to use the built-in IPsec VPN on Apple devices, or need "Connect on Demand" or excluded Wi-Fi networks automatically configured, see the Apple IPsec client setup guide for detailed configuration instructions.

Android Copy Section

WireGuard is used to provide VPN services on Android. Install the WireGuard VPN Client. Import the corresponding wireguard/<name>.conf file to your device, then set up a new connection with it. See the Android setup guide for detailed installation and configuration instructions.

Windows Copy Section

WireGuard is used to provide VPN services on Windows. Algo generates a WireGuard configuration file, wireguard/<username>.conf, for each user defined in config.cfg.

Install the WireGuard VPN Client. Import the generated wireguard/<username>.conf file to your device, then set up a new connection with it. See the Windows setup instructions for more detailed walkthrough and troubleshooting.

Linux Copy Section

Linux clients can use either WireGuard or IPsec:

WireGuard: WireGuard works great with Linux clients. See the Linux WireGuard setup guide for step-by-step instructions on configuring WireGuard on Ubuntu and other distributions.

IPsec: For strongSwan IPsec clients (including OpenWrt, Ubuntu Server, and other distributions), see the Linux IPsec setup guide for detailed configuration instructions.

OpenWrt Copy Section

For OpenWrt routers using WireGuard, see the OpenWrt WireGuard setup guide for router-specific configuration instructions.

Other Devices Copy Section

For devices not covered above or manual configuration, you'll need specific certificate and configuration files. The files you need depend on your device platform and VPN protocol (WireGuard or IPsec).

* ipsec/manual/cacert.pem: CA Certificate
* ipsec/manual/<user>.p12: User Certificate and Private Key (in PKCS#12 format)
* ipsec/manual/<user>.conf: strongSwan client configuration
* ipsec/manual/<user>.secrets: strongSwan client configuration
* ipsec/apple/<user>.mobileconfig: Apple Profile
* wireguard/<user>.conf: WireGuard configuration profile
* wireguard/<user>.png: WireGuard configuration QR code

Setup an SSH Tunnel Copy Chapter

If you turned on the optional SSH tunneling role, local user accounts will be created for each user in config.cfg, and SSH authorized_key files for them will be in the configs directory (user.pem). SSH user accounts do not have shell access, cannot authenticate with a password, and only have limited tunneling options (e.g., ssh -N is required). This ensures that SSH users have the least access required to set up a tunnel and can perform no other actions on the Algo server.

Use the example command below to start an SSH tunnel by replacing <user> and <ip> with your own. Once the tunnel is set up, you can configure a browser or other application to use 127.0.0.1:1080 as a SOCKS proxy to route traffic through the Algo server:

ssh -D 127.0.0.1:1080 -f -q -C -N <user>@algo -i configs/<ip>/ssh-tunnel/<user>.pem -F configs/<ip>/ssh_config

SSH into Algo Server Copy Chapter

Your Algo server is configured for key-only SSH access for administrative purposes. Open the Terminal app, cd into the algo-master directory where you originally downloaded Algo, and then use the command listed on the success message:

ssh -F configs/<ip>/ssh_config <hostname>

where <ip> is the IP address of your Algo server. If you find yourself regularly logging into the server, it will be useful to load your Algo SSH key automatically. Add the following snippet to the bottom of ~/.bash_profile to add it to your shell environment permanently:

ssh-add ~/.ssh/algo > /dev/null 2>&1

Alternatively, you can choose to include the generated configuration for any Algo servers created into your SSH config. Edit the file ~/.ssh/config to include this directive at the top:

Include <algodirectory>/configs/*/ssh_config

where <algodirectory> is the directory where you cloned Algo.

Adding or Removing Users Copy Chapter

Algo makes it easy to add or remove users from your VPN server after initial deployment.

For IPsec users: You must have selected yes at the Do you want to retain the keys (PKI)? prompt during the initial server deployment. This preserves the certificate authority needed for user management. You should also save the p12 and CA key passwords shown during deployment, as they're only displayed once.

To add or remove users, first edit the users list in your config.cfg file. Add new usernames or remove existing ones as needed. Then navigate to the algo directory in your terminal and run:

macOS/Linux:

./algo update-users

Windows:

.\algo.ps1 update-users

After the process completes, new configuration files will be generated in the configs directory for any new users. The Algo VPN server will be updated to contain only the users listed in the config.cfg file. Removed users will no longer be able to connect, and new users will have fresh certificates and configuration files ready for use.

Privacy and Logging Copy Chapter

Algo takes a pragmatic approach to privacy. By default, we minimize logging while maintaining enough information for security and troubleshooting.

What IS logged by default:
* System security events (failed SSH attempts, firewall blocks, system updates)
* Kernel messages and boot diagnostics (with reduced verbosity)
* WireGuard client state (visible via sudo wg - shows last endpoint and handshake time)
* Basic service status (service starts/stops/errors)
* All logs automatically rotate and delete after 7 days

Privacy is controlled by two main settings in config.cfg:
* strongswan_log_level: -1 - Controls StrongSwan connection logging (-1 = disabled, 2 = debug)
* privacy_enhancements_enabled: true - Master switch for log rotation, history clearing, log filtering, and cleanup

To enable full debugging when troubleshooting, set both strongswan_log_level: 2 and privacy_enhancements_enabled: false. This will capture detailed connection logs and disable all privacy features. Remember to revert these changes after debugging.

After deployment, verify your privacy settings:

ssh -F configs/<server_ip>/ssh_config <hostname>
sudo /usr/local/bin/privacy-monitor.sh

Perfect privacy is impossible with any VPN solution. Your cloud provider sees and logs network traffic metadata regardless of your server configuration. And of course, your ISP knows you're connecting to a VPN server, even if they can't see what you're doing through it.

For the highest level of privacy, treat your Algo servers as disposable. Spin up a new instance when you need it, use it for your specific purpose, then destroy it completely. The ephemeral nature of cloud infrastructure can be a privacy feature if you use it intentionally.

Additional Documentation Copy Chapter

Setup Instructions for Specific Cloud Providers Copy Section

Install and Deploy from Common Platforms Copy Section

Setup VPN Clients to Connect to the Server Copy Section

Advanced Deployment Copy Section

If you've read all the documentation and have further questions, create a new discussion.

Endorsements Copy Chapter

I've been ranting about the sorry state of VPN svcs for so long, probably about

time to give a proper talk on the subject. TL;DR: use Algo.

-- Kenn White

Before picking a VPN provider/app, make sure you do some research

https://research.csiro.au/ng/wp-content/uploads/sites/106/2016/08/paper-1.pdf ... – or consider Algo

-- The Register

Algo is really easy and secure.

-- the grugq

I played around with Algo VPN, a set of scripts that let you set up a VPN in the cloud in very little time, even if you don’t know much about development. I’ve got to say that I was quite impressed with Trail of Bits’ approach.

-- Romain Dillet for TechCrunch

If you’re uncomfortable shelling out the cash to an anonymous, random VPN provider, this is the best solution.

-- Thorin Klosowski for Lifehacker

Contributing Copy Chapter

See our Development Guide for information on:
* Setting up your development environment
* Using prek hooks for code quality
* Running tests and linters
* Contributing code via pull requests

Support Algo VPN Copy Chapter

All donations support continued development. Thanks!

* We accept donations via PayPal and Patreon.
* Use our referral code when you sign up to Digital Ocean for a $10 credit.
* We also accept and appreciate contributions of new code and bugfixes via Github Pull Requests.

Algo is licensed and distributed under the AGPLv3. If you want to distribute a closed-source modification or service based on Algo, then please consider <a href="mailto:[email protected]">purchasing an exception</a> . As with the methods above, this will help support continued development.