Best Open-Source and Self-Hosted Alternatives to Calendly: Cal.com vs Easy!Appointments, Benchmarked

Published 5 September 2026. Cal.com and Easy!Appointments were deployed on a live VPS, constrained to 1 vCPU, and measured the same day. The remaining tools are described from their documentation and source and are labelled as not benchmarked.

1. The Verdict and the Resource Reality

Two projects dominate this category and they sit at opposite ends of the resource spectrum. On an identical 1 vCPU container limit, Cal.com idled at 1.05 GB of RAM and shipped an 8.05 GB image. Easy!Appointments idled at 27 MB and shipped an 877 MB image. Cold start: 61.6 seconds against 11.8.

That is a 38-fold difference in memory for software solving the same problem, and it is the whole decision. On a 4 GB VPS, Cal.com consumes a quarter of your memory before a single booking exists. Easy!Appointments leaves the machine essentially free. Whether that trade is worth it depends entirely on whether you need Cal.com’s team scheduling, its 60-plus integrations and its API, because that is what the gigabyte buys.

One finding from the measurements is worth stating before the tables, because it will cost you a support ticket if you miss it. Easy!Appointments rate-limits to 100 requests per 120 seconds per IP, and by default it identifies every visitor by the connecting address. Put it behind nginx without configuring the proxy trust setting and every visitor shares one bucket: after 100 page views in two minutes, your entire site returns 429 to everyone. We reproduced this, and section 5 has the one-line fix, verified.

Decision Matrix

Tool	Licence	Stack	Idle RAM	Image size	Best fit
Cal.com	AGPLv3	Next.js + PostgreSQL	1.05 GB (measured)	8.05 GB (measured)	Teams, integrations, API-driven products
Easy!Appointments	GPLv3	PHP 8.2 + MySQL	27 MB (measured)	877 MB (measured)	Solo practitioners, clinics, salons, small VPS
Rallly	AGPLv3	Next.js + PostgreSQL	not benchmarked	not benchmarked	Group polling, a Doodle replacement rather than a Calendly one
LibreBooking	GPLv3	PHP + MySQL	not benchmarked	not benchmarked	Rooms, equipment and resource scheduling
Nextcloud Appointments	AGPLv3	PHP, inside Nextcloud	not benchmarked	not benchmarked	Organisations already running Nextcloud

The last three are described from their documentation and source rather than from our own load testing. We benchmarked the two that answer the actual query, and we are not going to invent numbers for the others. Where this fits a wider stack is covered in our self-hosted SaaS architecture guide.

2. Total Cost of Ownership vs. Calendly

Calendly prices per seat. Self-hosting prices per server, and a server does not care how many colleagues you add. That is the whole arbitrage, and it inverts sharply with team size.

Scenario	Calendly Teams ($16/seat/mo)	Self-hosted (VPS + backup)	Year 1 delta
1 user	$192	$126	−$66
5 users	$960	$126	−$834
20 users	$3,840	$180 (larger VPS)	−$3,660
50 users	$9,600	$300 (larger VPS)	−$9,300

Calendly cost(n)   = seat_price x n x 12
Self-hosted cost   = V x 12                    (independent of n)

Breakeven in users, at V = $10.50/month and seat = $16/month:
  n = V / seat = 10.50 / 16 = 0.66 users

The crossover is below one seat: a single paid Calendly user already
costs more per year than the whole server.

But labour is the term the table omits:
  true_self_hosted = (V x 12) + (hours_per_month x 12 x your_rate)

At 1 h/month and $50/h:  126 + 600 = $726/year
  -> Calendly is cheaper below 4 seats. Above 4, self-hosting wins
     even when you price your own time at market rate.

That second calculation is the honest one, and it flips the naive conclusion. For a solo consultant, a $16 seat is cheaper than an hour of your month. The self-hosting case becomes compelling at roughly four seats, or immediately if you are already running a VPS for something else and the marginal cost is memory rather than money.

The cost lines that spreadsheets omit

Transactional email is not optional here. A booking tool that cannot send a confirmation is not a booking tool. A fresh VPS IP has no sending reputation and its mail lands in spam, which for this category means silently missed appointments. Budget $10 to $15 per month for a relay, which is close to a Calendly seat on its own.

Calendar sync is where the integration burden lands. Google Calendar and Microsoft 365 both require you to register an OAuth application, verify the domain, and maintain the credentials. Calendly does that once for everyone; self-hosting means you do it, per provider, and you renew it when it expires.

Availability is a feature you are now responsible for. A booking page that is down during business hours does not degrade gracefully; the prospect books with someone else. A single VPS has no failover, which for this category is a sharper trade-off than for a blog.

3. Deploying Easy!Appointments

The lightweight option, and the one that fits an entry-tier VPS without argument. PHP 8.2 and MySQL, deployed with Compose.

install -d -m 750 /opt/appointments && cd /opt/appointments

cat > .env <<EOF
MYSQL_ROOT_PASSWORD=$(openssl rand -hex 16)
MYSQL_PASSWORD=$(openssl rand -hex 16)
EOF
chmod 600 .env

# /opt/appointments/docker-compose.yml
services:
  mysql:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: easyappointments
      MYSQL_USER: ea
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - eadb:/var/lib/mysql
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h localhost -u root -p$$MYSQL_ROOT_PASSWORD"]
      interval: 10s
      timeout: 5s
      retries: 10
    cpus: 0.5
    mem_limit: 1g

  app:
    image: alextselegidis/easyappointments:latest
    restart: unless-stopped
    depends_on:
      mysql:
        condition: service_healthy
    environment:
      BASE_URL: https://booking.example.com
      DB_HOST: mysql
      DB_NAME: easyappointments
      DB_USERNAME: ea
      DB_PASSWORD: ${MYSQL_PASSWORD}
      DEBUG_MODE: "FALSE"
    ports:
      - "127.0.0.1:8091:80"
    cpus: 1.0
    mem_limit: 1g

volumes:
  eadb:

docker compose config --quiet
docker compose up -d
docker compose ps

The 127.0.0.1: prefix on the published port is not cosmetic. Docker writes iptables rules consulted before UFW, so a container published as 8091:80 is reachable from the internet even when the firewall reports the port as denied. Binding to loopback makes the container reachable only by the reverse proxy on the same host. Verify it:

ss -tln | grep 8091
# Expect: LISTEN 0 4096 127.0.0.1:8091 0.0.0.0:*
# If you see 0.0.0.0:8091, your booking database is on the public internet.

nginx and TLS

# /etc/nginx/sites-available/booking.conf
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name booking.example.com;

    ssl_certificate     /etc/letsencrypt/live/booking.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/booking.example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    client_max_body_size 16M;
    access_log /var/log/nginx/booking-access.log;
    error_log  /var/log/nginx/booking-error.log;

    location / {
        proxy_pass http://127.0.0.1:8091;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 60s;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name booking.example.com;
    return 301 https://booking.example.com$request_uri;
}

ln -s /etc/nginx/sites-available/booking.conf /etc/nginx/sites-enabled/booking.conf
nginx -t && systemctl reload nginx
certbot --nginx -d booking.example.com --redirect --agree-tos -m you@example.com --non-interactive

Sending X-Forwarded-For is necessary but not sufficient. Section 5 explains why the application ignores it until you tell it which proxy to trust, and what happens to your booking page when you forget.

4. Deploying Cal.com

The heavyweight, and the one that actually replaces Calendly feature for feature. Budget the disk before you start: the image alone is 8.05 GB, which on a 50 GB VPS is 16% of your storage before the database exists.

df -h /                    # confirm at least 15 GB free before pulling
install -d -m 750 /opt/calcom && cd /opt/calcom

cat > .env <<EOF
POSTGRES_PASSWORD=$(openssl rand -hex 16)
NEXTAUTH_SECRET=$(openssl rand -base64 32)
CALENDSO_ENCRYPTION_KEY=$(openssl rand -base64 32)
EOF
chmod 600 .env

# /opt/calcom/docker-compose.yml
services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: calcom
      POSTGRES_USER: calcom
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - caldb:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U calcom -d calcom"]
      interval: 10s
      timeout: 5s
      retries: 10
    cpus: 0.5
    mem_limit: 1g

  calcom:
    image: calcom/cal.com:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DATABASE_URL: postgresql://calcom:${POSTGRES_PASSWORD}@postgres:5432/calcom
      DATABASE_DIRECT_URL: postgresql://calcom:${POSTGRES_PASSWORD}@postgres:5432/calcom
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
      CALENDSO_ENCRYPTION_KEY: ${CALENDSO_ENCRYPTION_KEY}
      NEXT_PUBLIC_WEBAPP_URL: https://cal.example.com
      NEXTAUTH_URL: https://cal.example.com/api/auth
      NEXT_PUBLIC_LICENSE_CONSENT: "agree"
    ports:
      - "127.0.0.1:8092:3000"
    cpus: 1.0
    mem_limit: 2g

volumes:
  caldb:

docker compose up -d
# Prisma migrations run on first boot. Measured cold start: 61.6 s.
docker compose logs -f calcom
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8092/auth/setup

CALENDSO_ENCRYPTION_KEY deserves the same treatment as an SSH key. It encrypts the OAuth credentials Cal.com stores for every connected Google and Microsoft calendar. Regenerate it during a rebuild and every integration your users configured becomes undecryptable, with no recovery path other than reconnecting each one by hand.

The reverse proxy configuration is the same shape as section 3, with one addition: Cal.com is a Next.js application and its editor uses websockets, so add the upgrade headers.

    location / {
        proxy_pass http://127.0.0.1:8092;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade           $http_upgrade;
        proxy_set_header Connection        "upgrade";
        proxy_read_timeout 120s;
    }

For the firewall, fail2ban and certificate renewal work that belongs alongside either deployment, see our Ubuntu 24.04 server hardening walkthrough. If you are considering a commercial booking script from a marketplace instead, audit it first with the protocol in our CodeCanyon security audit checklist.

Migrating off Calendly without losing the bookings

The switch has one hazard, and it is not technical. Your Calendly link is embedded in email signatures, on business cards, in calendar invitations already sent, and on pages you no longer control. Deleting the account breaks all of them silently.

• Stand the new instance up first and use it in parallel. Both booking pages live simultaneously for at least one full booking cycle, which for most businesses means a month.
• Export existing bookings before touching the subscription. Calendly exports scheduled events to CSV. Do this while the account is active; a downgraded or cancelled account restricts export.
• Recreate availability rules by hand and verify against a real week. Buffers, minimum notice, daily caps and timezone handling do not transfer, and a timezone error books people at the wrong hour without failing visibly.
• Redirect the old link rather than deleting it. Keep the Calendly account on its free tier and point its event description at the new URL. A free seat costing nothing beats a dead link on a business card printed last year.
• Send yourself a real booking end to end on the new instance: form submission, confirmation email, calendar entry, reminder, and cancellation. Then do it again from a different email provider, because deliverability differs.

The step people skip is the last one. A self-hosted booking tool that cannot deliver mail is worse than no booking tool, because it accepts appointments and then tells nobody. Test cancellation and rescheduling too; those emails travel a different code path than the confirmation and fail independently.

5. Benchmarks: Cal.com vs. Easy!Appointments, Measured

Methodology. Both stacks deployed with Docker Compose on Ubuntu 24.04.4 LTS, host AMD EPYC 9354P with 2 vCPU and 7.8 GiB RAM. Each application container was limited to cpus: 1.0, its database to cpus: 0.5, to emulate an entry-tier VPS. Load generator: ApacheBench 2.3 on the same host, which competes for the same cores and makes every figure a conservative floor. Versions: Cal.com from the calcom/cal.com:latest image with PostgreSQL 16, Easy!Appointments from alextselegidis/easyappointments:latest on PHP 8.2 with MySQL 8.0.

Resource footprint

Metric	Easy!Appointments	Cal.com	Ratio
Application container, idle	27.4 MB	1.05 GB	38x
Database container, idle	358 MB (MySQL 8)	38 MB (PostgreSQL 16)	0.1x
Total idle	385 MB	1.09 GB	2.8x
Total under sustained load	558 MB	1.31 GB	2.3x
Application image	877 MB	8.05 GB	9.2x
Total disk, images	1.98 GB	8.47 GB	4.3x
Cold start to first response	11.8 s	61.6 s	5.2x

The database row inverts the story and is worth reading carefully. MySQL 8 idled at 358 MB against PostgreSQL 16’s 38 MB — MySQL’s default buffer pool is simply larger out of the box. On a memory-constrained VPS, tuning innodb_buffer_pool_size down recovers most of Easy!Appointments’ footprint, whereas nothing you configure recovers a gigabyte from a Next.js process.

Throughput

Concurrency	Easy!Appointments (89,833-byte booking page)			Cal.com (369,014-byte app page)
	req/s	P50	P95	req/s	P50	P95
1	35.1	27 ms	38 ms	16.1	51 ms	109 ms
10	43.0	231 ms	340 ms	17.4	521 ms	1,318 ms
25	42.3	596 ms	798 ms	15.7	1,320 ms	2,278 ms
TTFB, single request	24 ms			55 ms

Zero failed requests in every run once the rate limiter was accounted for. Both plateau: Easy!Appointments at roughly 43 requests per second, Cal.com at roughly 16.4, in each case with latency scaling linearly beyond that point rather than throughput rising.

Do not read those two columns as a like-for-like race. The pages differ by a factor of four in size, and the Cal.com page is an authenticated application view while the Easy!Appointments page is a public booking form. Measured in bytes served, the ranking reverses:

Easy!Appointments:  43.0 req/s x  89,833 bytes = 3.86 MB/s
Cal.com:            16.4 req/s x 369,014 bytes = 6.05 MB/s

Cal.com moves 57% more data per second. It is not slower software; it is heavier software serving a heavier page. The number that should drive your decision is the memory footprint, not the request rate, because both figures are far above what a booking page ever needs. Forty-three requests per second is 3.7 million page views a day.

The rate limiter that will break your booking page

Our first Easy!Appointments load tests reported large numbers of non-2xx responses that a single manual request could not reproduce. The server log settled it:

$ docker logs lab-ea-app-1 | grep -oE '" [0-9]{3} ' | sort | uniq -c
     81 " 200 
    125 " 429 

Easy!Appointments ships a rate limiter, enabled by default, allowing 100 requests per 120 seconds per IP address. The helper is unambiguous:

// application/helpers/rate_limit_helper.php
function rate_limit(string $ip, int $max_requests = 100, int $duration = 120): void

// application/core/EA_Controller.php
rate_limit($this->input->ip_address());

CodeIgniter’s ip_address() returns the connecting address and ignores X-Forwarded-For entirely unless proxy_ips is configured. It ships empty. Behind a reverse proxy, every visitor therefore presents the same address, and they all share one bucket. We reproduced the consequence directly: after exhausting the quota from one source, three distinct simulated visitors were all refused.

# Quota exhausted from one address, then three different visitors:
  visitor 198.51.100.1   -> 429
  visitor 198.51.100.2   -> 429
  visitor 203.0.113.99   -> 429

One hundred page views across your whole site in two minutes, and everyone gets an error page. The fix is one line, and we verified it works rather than assuming:

# application/config/config.php — set to your reverse proxy's address or CIDR
$config['proxy_ips'] = '127.0.0.1';        # nginx on the same host
# or, for a container network:
$config['proxy_ips'] = '172.18.0.0/16';

# After the fix, buckets are per-visitor again:
  visitor 198.51.100.10 (quota spent) -> 429
  visitor 198.51.100.99 (fresh)       -> 200

Set it in a mounted configuration file rather than editing inside the container, or the change disappears on your next docker compose pull. And a general lesson beyond this application: when a load test reports errors your browser cannot reproduce, read the server’s own access log before adjusting the benchmark. The application was reporting a real behaviour correctly; only the interpretation was wrong.

Feature comparison against Calendly

Capability	Calendly	Cal.com	Easy!Appointments
Personal booking page	Yes	Yes	Yes
Multiple event types	Yes	Yes	Yes (services)
Google / Microsoft calendar sync	Yes, managed	Yes, you register the OAuth app	Yes, Google and CalDAV
Team round-robin and collective events	Paid tiers	Yes	No
Payment collection	Paid tiers	Stripe and others	Limited
Public API and webhooks	Paid tiers	Yes	REST API
Embeddable widget	Yes	Yes	Yes, iframe
Staff and resource management	Limited	Teams	Providers, services, working plans
Where your customers’ data lives	Their servers	Yours	Yours

Two rows carry most of the decision. Team round-robin is the feature that separates the two open-source options for anything beyond a solo operator: Cal.com models a team distributing bookings among members, and Easy!Appointments does not. And the last row is the reason the category exists at all — under GDPR, a booking form collects names, email addresses, phone numbers and often a free-text reason for the appointment, which for a clinic or a lawyer is data you may prefer not to place on a third party’s infrastructure at all.

Easy!Appointments models providers and services rather than event types, which reads as a limitation until you need it: a salon with four stylists, each offering different services with different durations, maps onto it directly and onto a personal booking page badly.

6. The Other Options, and When They Are the Right Answer

These were not deployed or benchmarked for this article. What follows is drawn from their documentation and source, and is included because each answers a question the two benchmarked tools answer badly.

Rallly

AGPLv3, Next.js and PostgreSQL. Rallly solves group polling — proposing several slots and letting a group converge on one — which is the Doodle problem, not the Calendly problem. If what you need is “when can the six of us meet”, Cal.com is the wrong tool and Rallly is the right one. If what you need is “let strangers book time in my calendar”, the reverse holds. Being a Next.js application, expect a footprint closer to Cal.com’s than to Easy!Appointments’.

LibreBooking

GPLv3, PHP and MySQL, a maintained fork of Booked Scheduler. Its model is resources rather than people: rooms, equipment, vehicles, lab instruments, with quotas and approval workflows. A university booking microscopes or a co-working space booking desks is squarely its use case, and shoehorning Calendly-style personal scheduling into it fights the data model.

Nextcloud Appointments

An app inside Nextcloud rather than standalone software. If your organisation already runs Nextcloud, the marginal cost is close to zero and calendar synchronisation is solved because the calendar is already there. If you do not run Nextcloud, installing it to obtain a booking page is a far larger commitment than either tool in section 5.

Choosing between them

• One person, a booking page, a small VPS. Easy!Appointments. 27 MB, and you will never think about it again.
• A team, calendar integrations, an API you build against. Cal.com, and provision 4 GB rather than 2.
• Finding a slot that suits a group. Rallly. The other two model this badly.
• Rooms, equipment, shared resources. LibreBooking.
• Already running Nextcloud. Its Appointments app, before installing anything else.

What self-hosting actually costs you in attention

Both tools update frequently, and a booking page is a service your customers depend on at specific hours. Three obligations follow, and they are the ones the price comparison in section 2 prices at one hour a month.

Pin your image tags. Running latest means an unattended docker compose pull can change behaviour under live bookings. Pin an explicit version, read the release notes, and upgrade deliberately during a quiet window. Cal.com in particular runs Prisma migrations on boot, so an upgrade is a schema change whether or not you thought of it that way.

Watch certificate expiry as a business risk. An expired certificate on a blog is embarrassing. On a booking page it stops bookings entirely, and the failure arrives 90 days after you last thought about it. Run certbot renew --dry-run from cron monthly and alert on its exit code, not on the renewal itself.

Monitor from outside the machine. A check running on the same VPS reports healthy right up until the VPS is the problem. A free external uptime monitor hitting the public booking URL every five minutes is the single highest-value addition to either deployment, and it costs nothing.

7. Frequently Asked Questions

What is the best open-source alternative to Calendly?

Cal.com for teams and integrations, Easy!Appointments for a single practitioner on a small server. We measured Cal.com idling at 1.05 GB of RAM with an 8.05 GB image, against 27 MB and 877 MB for Easy!Appointments. Cal.com matches Calendly feature for feature; Easy!Appointments covers booking pages and leaves the machine free.

How much RAM do I need to self-host Cal.com?

Provision 4 GB. We measured 1.05 GB at idle and 1.31 GB under sustained load for the application container alone, plus 38 MB for PostgreSQL. A 2 GB VPS runs it but leaves nothing for the reverse proxy, backups or a second application. Disk matters equally: the image alone is 8.05 GB.

Is self-hosting a booking tool cheaper than Calendly?

Above roughly four seats, yes, even valuing your own time at market rate. A $10.50 monthly VPS plus one maintenance hour at $50 costs about $726 a year, against $192 per Calendly seat. Below four seats Calendly wins on cost, and the honest reason to self-host is data control rather than price.

Why does my self-hosted booking page return 429 errors?

Easy!Appointments rate-limits to 100 requests per 120 seconds per IP, and CodeIgniter ignores X-Forwarded-For until proxy_ips is configured. Behind a reverse proxy every visitor presents the proxy’s address and shares one bucket, so the whole site fails after 100 views. Set $config['proxy_ips'] to your proxy’s address.

Can I run Cal.com on a $6 VPS?

Only on the larger entry tiers. Cal.com needs about 1.3 GB of RAM under load and 8.47 GB of disk for its images, so a 1 GB or 2 GB instance is not viable. An entry-tier VPS with 4 GB and 50 GB of disk runs it, with the image consuming 16% of that storage before your first booking.

8. Final Production Checklist

# Container not publicly bound. Check first, always.
ss -tln | grep -E '809[12]'          # expect 127.0.0.1 only, never 0.0.0.0

# DNS and TLS
dig +short A booking.example.com | wc -l          # expect: 1
certbot renew --dry-run
curl -sI https://booking.example.com/ | grep -i strict-transport

# Easy!Appointments: the rate limiter knows who your visitors are
grep -n "proxy_ips" /opt/appointments/config/config.php    # must NOT be ''
for ip in 198.51.100.1 198.51.100.2; do
  curl -s -o /dev/null -w "$ip %{http_code}\n" \
    -H "X-Forwarded-For: $ip" https://booking.example.com/
done   # both 200 after exhausting a third address = per-visitor buckets

# Cal.com: the encryption key exists somewhere other than this server
grep CALENDSO_ENCRYPTION_KEY /opt/calcom/.env
# Lose it and every connected Google and Microsoft calendar must be reconnected.

# Email actually arrives. For a booking tool this is the product.
# Send a real test booking and confirm the message lands in an inbox,
# not in spam, from an address whose SPF and DKIM you control.

# Backups, encrypted, off the machine
docker compose exec -T postgres pg_dump -U calcom -d calcom | gzip \
  | gpg --batch --yes --symmetric --cipher-algo AES256 \
        --passphrase-file /root/.backup-passphrase > /var/backups/cal-$(date +%F).sql.gz.gpg
# MySQL equivalent for Easy!Appointments:
docker compose exec -T mysql mysqldump --no-tablespaces -u root -p"$MYSQL_ROOT_PASSWORD" \
  easyappointments | gzip > /var/backups/ea-$(date +%F).sql.gz

# Survives a reboot, because a booking page down at 09:00 loses the booking
grep -c 'restart: unless-stopped' docker-compose.yml    # expect: 2
systemctl is-enabled docker
reboot   # then re-run the HTTPS checks

# The restore works. The only test that counts.

The email line is the one people skip and the one this category punishes hardest. A blog whose mail fails is an inconvenience. A booking tool whose confirmations land in spam produces appointments nobody knows about, and you discover it from the customer who did not show up.

If you benchmark either tool on comparable hardware and get materially different numbers, send us the ab output and your Compose file and we will publish the comparison. For how hosting choice changes these trade-offs, see our Cloudways vs. Hostinger VPS comparison.