Running Self-Hosted Supabase on ARM64: Complete Guide for Graviton and Raspberry Pi

ARM64 processors are everywhere in 2026—from AWS Graviton instances promising 40% better price-performance to Raspberry Pi clusters in home labs. If you're self-hosting Supabase, running on ARM64 can significantly reduce your infrastructure costs. But getting Supabase to work properly on ARM architecture isn't always straightforward.

This guide covers the practical steps to deploy self-hosted Supabase on ARM64, including the workarounds for common issues and when ARM makes sense for your use case.

Why ARM64 for Self-Hosted Supabase?

The economics are compelling. AWS Graviton3 instances offer roughly 40% better price-performance compared to equivalent x86 instances. For a production Supabase deployment that might otherwise cost $150/month on x86, you could see that drop to under $100 on Graviton.

Beyond cloud savings, ARM opens up interesting deployment options:

• AWS Graviton: Production-ready ARM instances with excellent PostgreSQL performance
• Oracle Cloud Free Tier: ARM instances with up to 24GB RAM and 4 OCPUs—free forever
• Raspberry Pi: Perfect for development, home labs, or edge deployments
• Apple Silicon Macs: Native performance for local development on M1/M2/M3 Macs

The trade-off? Some Supabase Docker images weren't originally built for ARM, and you may encounter compatibility issues that require manual intervention.

Prerequisites

Before starting, ensure you have:

• An ARM64 host (Graviton, Raspberry Pi 4/5, Apple Silicon Mac, or ARM VM)
• At least 4GB RAM (8GB+ recommended for production)
• Docker and Docker Compose installed
• Basic familiarity with Docker Compose for Supabase

For Raspberry Pi specifically, you'll need a 64-bit OS—Raspberry Pi OS (64-bit) or Ubuntu Server 22.04+.

Deploying on AWS Graviton

Graviton instances are the most straightforward ARM64 option because AWS provides a first-class ARM experience.

Recommended Instance Types

The t4g family uses burstable credits, which works well for development but can cause performance issues under sustained load. For production, consider the m7g family.

Step 1: Launch Your Graviton Instance

When launching an EC2 instance:

1. Select an ARM64 AMI (Ubuntu 24.04 ARM64 or Amazon Linux 2023 ARM64)
2. Choose a Graviton instance type (t4g, m7g, c7g, or r7g family)
3. Allocate at least 30GB EBS storage (gp3 recommended)
4. Configure security groups to allow ports 80, 443, and 8000

Step 2: Install Docker

# Ubuntu
sudo apt update && sudo apt install -y docker.io docker-compose-v2

# Add your user to the docker group
sudo usermod -aG docker $USER

# Log out and back in, then verify
docker --version

Step 3: Clone and Configure Supabase

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

# Copy the example environment file
cp .env.example .env

Edit .env to set secure values for:

• POSTGRES_PASSWORD
• JWT_SECRET
• ANON_KEY and SERVICE_ROLE_KEY
• DASHBOARD_USERNAME and DASHBOARD_PASSWORD

Refer to the environment variables guide for a complete breakdown.

Step 4: Start the Stack

docker compose up -d

On Graviton, this should work without modifications since Supabase's official images now support ARM64.

Deploying on Raspberry Pi

Raspberry Pi deployments are more challenging because of memory constraints and potential page size issues on newer Pi models.

Raspberry Pi 5 Page Size Issue

Raspberry Pi 5 uses 16KB memory pages by default, but PostgreSQL and some other services expect 4KB pages. You have two options:

Option A: Change the page size to 4KB (Recommended)

Edit your boot configuration:

sudo nano /boot/firmware/config.txt

Add this line at the end:

kernel=kernel8.img

Then create a kernel command line override:

sudo nano /boot/firmware/cmdline.txt

Add kernel_pagesize=4k to the existing line (don't create a new line).

Reboot:

sudo reboot

Verify the change:

getconf PAGE_SIZE
# Should output: 4096

Option B: Disable problematic services

If you can't change page size, disable supabase-vector in docker-compose.yml:

# Comment out or remove the vector service
# vector:
#   image: timberio/vector:...

Raspberry Pi Memory Optimization

With only 4-8GB RAM on most Pi models, you'll want to optimize:

# In docker-compose.yml, add memory limits
services:
  db:
    deploy:
      resources:
        limits:
          memory: 1G
  
  rest:
    deploy:
      resources:
        limits:
          memory: 256M
  
  # Similar limits for other services

You can also disable services you don't need. If you're not using Realtime, Edge Functions, or Vector:

docker compose up -d db rest auth storage kong studio

Recommended Raspberry Pi Models

Deploying on Apple Silicon (M1/M2/M3)

Apple Silicon Macs are excellent for local development. Docker Desktop on macOS handles ARM translation automatically, but native ARM images perform better.

Common Issue: Memory Allocation

The default Docker Desktop memory allocation (2GB) is insufficient for Supabase. Increase it:

1. Open Docker Desktop → Settings → Resources
2. Increase Memory to at least 8GB (16GB recommended)
3. Increase Swap to 2GB
4. Click Apply & Restart

Running Supabase Locally

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env
docker compose up -d

Access Studio at http://localhost:8000.

Building ARM64 Images Manually

If you encounter issues with official images, you may need to build them yourself.

Building supabase/postgres for ARM64

The most common problematic image is the PostgreSQL container. To build it:

git clone https://github.com/supabase/postgres
cd postgres

# Build for ARM64
docker build --platform=linux/arm64 -t supabase-postgres:local-arm64 .

Then update your docker-compose.yml to use the local image:

services:
  db:
    image: supabase-postgres:local-arm64
    # ... rest of configuration

Using Community ARM64 Images

The community maintains ARM64-optimized Supabase configurations:

• webysther/supabase-docker — Optimized for self-hosting
• berkedel/supabase-rpi4 — Minimal setup for Raspberry Pi 4

These projects remove unnecessary dependencies and optimize for constrained environments.

Performance Tuning for ARM64

ARM processors have different performance characteristics than x86. Here's how to optimize PostgreSQL for ARM:

PostgreSQL Configuration

Edit volumes/db/postgresql.conf or set these via environment variables:

# Memory settings (adjust based on available RAM)
shared_buffers = 1GB           # 25% of total RAM
effective_cache_size = 3GB     # 75% of total RAM
work_mem = 64MB
maintenance_work_mem = 256MB

# ARM-specific: Graviton has excellent memory bandwidth
huge_pages = try

# Connection settings
max_connections = 100

Monitoring Resource Usage

Use docker stats to identify bottlenecks:

docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Watch for services exceeding their memory limits or consistently hitting 100% CPU.

When ARM64 Makes Sense (And When It Doesn't)

ARM64 is a good fit when:

• Cost is primary concern: 30-40% savings on cloud compute
• Development/testing: Apple Silicon Macs, Raspberry Pi home labs
• Edge deployments: IoT or on-premise installations
• Oracle Cloud Free Tier: 24GB RAM ARM instances at no cost

Stick with x86 when:

• You need maximum compatibility: Some PostgreSQL extensions may not have ARM builds
• Your team lacks ARM experience: Debugging ARM-specific issues adds overhead
• You're using managed services: Most integrate better with x86 instances
• Workload is memory-bound: Some x86 instances offer higher memory-to-cost ratios

Troubleshooting Common ARM64 Issues

"exec format error"

This means Docker is trying to run an x86 image on ARM:

# Check image architecture
docker inspect supabase/postgres:latest | grep Architecture

Solution: Build the image for ARM64 or find an ARM64-compatible alternative.

"Cannot allocate memory"

Your container is requesting more memory than available:

# Check available memory
free -h

# Reduce PostgreSQL shared_buffers

"Database is starting up" loop

Often caused by page size mismatch (Raspberry Pi 5) or insufficient shared memory:

# Check logs
docker logs supabase-db

# Verify page size
getconf PAGE_SIZE

Realtime service crashes

The Elixir-based Realtime service can be memory-hungry. Either allocate more RAM or disable it if you don't need real-time subscriptions.

Cost Comparison: ARM64 vs x86

Based on current AWS pricing (us-east-1):

Combined with other cost optimizations, ARM deployments can significantly reduce your Supabase infrastructure spend.

Simplifying ARM64 Deployments with Supascale

Managing ARM-specific configurations, building custom images, and tuning PostgreSQL for different architectures adds operational overhead. Supascale handles these complexities automatically:

• One-click deployment on your ARM64 infrastructure
• Automated backups to S3-compatible storage
• Custom domain setup with free SSL certificates
• OAuth configuration through a visual interface

Instead of debugging page size issues or building ARM images manually, you can focus on building your application. Supascale costs $39.99 once and supports unlimited projects—whether they're running on Graviton, Raspberry Pi, or traditional x86 servers.

Conclusion

ARM64 offers compelling cost savings for self-hosted Supabase deployments, but it requires more upfront configuration than x86. AWS Graviton provides the smoothest experience, while Raspberry Pi deployments need careful attention to memory constraints and system configuration.

The key takeaways:

1. Graviton is production-ready — Official images work, savings are real
2. Raspberry Pi requires work — Page size fixes, memory optimization, possibly disabled services
3. Apple Silicon is great for development — Just increase Docker memory allocation
4. Build custom images if needed — When official images fail, build for ARM64 yourself

If managing ARM-specific configurations seems like too much overhead, consider tools like Supascale that abstract away infrastructure complexity regardless of your underlying architecture.

Further Reading

• How to Deploy Supabase on Your Own Server
• Docker Compose for Supabase: Production Best Practices
• The True Cost of Self-Hosting Supabase
• Best VPS Providers for Self-Hosted Supabase