Introduction
If you've ever built a "quick tracker" in a spreadsheet and watched it grow into something unmanageable — dropdowns that don't validate, formulas that break when someone sorts the wrong column, five people editing the same file over email — NocoDB is the fix for that. It takes a real database and puts a spreadsheet on top of it, so you get the structure of a database with the editing experience of Excel or Google Sheets.
A lot of people know it as the open-source Airtable alternative, and that's a fair description. The difference that matters for a homelab is that your data lives on your own Proxmox node instead of someone else's cloud, and there's no per-seat pricing to worry about six months from now.
This guide walks you through installing NocoDB inside an LXC container on Proxmox VE 9.2, using Docker to run it. Budget about 20 minutes: five for the container, ten for Docker and NocoDB, and the rest for signing in and poking around.
What You Will Learn
- How to size and create a Debian 13 LXC container for running Docker
- Why unprivileged containers need the nesting feature turned on before Docker will work
- How to install Docker Engine inside the container using Docker's official repository
- How to deploy NocoDB with its official quick-install script
- How to sign in for the first time and what the default setup actually gives you
- How to back up, update, and troubleshoot the install once it's running
What Is This Feature?
NocoDB is an open-source application that connects to a database — by default, PostgreSQL — and generates a spreadsheet-style interface on top of it automatically. Every table becomes a grid you can filter, sort, and edit inline. You also get forms for data entry, Kanban boards, gallery views for image-heavy tables, and a REST API for every base you create, without writing a line of backend code.
To run it on Proxmox, you'll use two things this site has covered before but that are worth a one-line refresher if you're new: LXC and Docker.
An LXC container is Proxmox's lightweight way of running a Linux system. Unlike a full virtual machine, it shares the host's kernel, so it starts in a couple of seconds and uses a fraction of the RAM a VM would need for the same job. It's the right tool here because NocoDB doesn't need its own kernel, custom hardware access, or a separate OS — it just needs a Linux box to run Docker in.
Docker packages an application and everything it depends on — the right Node.js version, system libraries, config files — into a single "container image" that runs the same way regardless of what's installed on the host. NocoDB publishes official Docker images, and the project's own install script sets up Docker Compose for you, which is why Docker is the easiest path here rather than installing NocoDB's dependencies by hand.
Why Would You Use It?
The obvious use case is replacing Airtable, Notion databases, or a shared Google Sheet that's turned into a mess. But in a homelab specifically, NocoDB tends to end up as the place people track things nothing else quite fits:
- A hardware or license inventory — what's plugged into which UPS, which app has which license key, when a domain renews
- A simple internal CRM for a side business or club, with linked tables for contacts, orders, and follow-ups
- A media or book catalog with cover images, ratings, and a Kanban "to watch / watching / done" board
- A lightweight project tracker when a full tool like Jira or Linear is overkill for what you're doing
None of that requires enterprise infrastructure. It requires one small container and about 2 GB of RAM, which is why it's a reasonable weekend project rather than a big commitment.
Prerequisites
Before you start, make sure you have:
- Proxmox VE 8.x or 9.x with a node that has free CPU, RAM, and storage to spare
- Root access to the Proxmox web interface or shell
- A Debian 13 (or Debian 12) LXC template available — you'll download this if you don't already have it
- At least 2 vCPU cores, 2 GB of RAM, and 12 GB of disk space you can dedicate to the container
- Your Proxmox host connected to the internet, since Docker will be pulling images from Docker Hub
You don't need a static IP for this, but it makes life easier later if you decide to put NocoDB behind a reverse proxy. If you haven't set one up yet, it's worth doing before you go further.
Step-by-Step Tutorial
Step 1: Download the Debian 13 template
In the Proxmox shell (or via SSH to the node), refresh the list of available templates and grab Debian 13:
pveam update
pveam available --section system | grep debian-13
pveam download local debian-13-standard_13.1-2_amd64.tar.zstThe exact filename changes with every point release, so run the pveam available command first and copy whatever version it actually lists — don't assume the one above is current by the time you read this.
Step 2: Create the container
In the web UI, click Create CT in the top-right corner. Work through the wizard:
- General — pick a CT ID, set the hostname to something like
nocodb, and set a root password - Template — select the Debian 13 template you just downloaded
- Disks — 12 GB is comfortable; NocoDB's stack pulls four Docker images (app, worker, Postgres, Redis) that together run around 1.5 GB, and you want headroom for logs and data growth
- CPU — 2 cores is plenty for a homelab-scale deployment
- Memory — 2048 MB, with a small swap allocation left at its default
- Network — attach to
vmbr0(or whichever bridge your VMs use) and assign a static IP or leave it on DHCP
Leave Unprivileged container checked. It's the safer default, and Docker runs fine in an unprivileged container once you enable one setting in the next step.
Step 3: Enable nesting
Docker needs to create its own mount namespaces and cgroups, which an unprivileged LXC container blocks by default for security reasons. You have to explicitly allow it.
Before starting the container, go to Options → Features in the container's settings and check Nesting. Or do it from the shell, replacing 200 with your container's actual ID:
pct set 200 -features nesting=1,keyctl=1Skip this step and Docker will fail with a permissions error the moment you try to start a container — it's the single most common reason this whole setup doesn't work on the first try.
Step 4: Start the container and update packages
pct start 200
pct enter 200You're now inside the container's shell. Update the package list and install the tools Docker's installer needs:
apt update && apt install -y ca-certificates curl gnupgStep 5: Install Docker Engine
Add Docker's official GPG key and repository, then install Docker itself. This is Docker's standard installation method for Debian, straight from their docs:
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
tee /etc/apt/sources.list.d/docker.list > /dev/null
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-pluginConfirm it actually works before moving on:
docker run hello-worldIf you see the "Hello from Docker!" message, the daemon is up and nesting is configured correctly. If it hangs or throws a permissions error, go back and check Step 3.
Step 6: Install NocoDB
NocoDB publishes an install script that sets up a complete Docker Compose stack for you — the app, a background worker, PostgreSQL for storage, and Redis for caching and job queues. Run it from your home directory inside the container:
curl -fsSL https://install.nocodb.com/noco.sh | bash -s -- --quickThis creates a nocodb/ folder with a ready-made docker-compose.yml inside it, pulls the four images, and starts everything. On a typical home internet connection this takes two to four minutes, most of it spent downloading images.
Step 7: Log in for the first time
Find the container's IP address if you don't already know it:
ip a | grep inetThen open http://<container-ip>:8080 in a browser on your LAN. NocoDB doesn't ship with a default account — the first person to sign up with an email and password becomes the super admin for that instance. Use a real password here; there's no separate "change it later" prompt forcing you to.
Commands Explained
| Command | What it does |
|---|---|
pveam download local debian-13-standard... | Downloads an LXC template into the node's local template storage so it's available when creating a container |
pct set 200 -features nesting=1,keyctl=1 | Enables the kernel features an unprivileged container needs to run Docker safely inside it |
pct enter 200 | Drops you into the container's shell directly from the Proxmox host, without needing SSH |
docker run hello-world | Pulls a tiny test image and runs it, confirming the Docker daemon is reachable and working |
curl ... noco.sh | bash -s -- --quick | Downloads and runs NocoDB's official installer, which writes a Docker Compose file and starts the full stack |
docker compose logs -f nocodb | Streams live log output from the NocoDB application container, useful when something isn't starting |
docker compose pull && docker compose up -d | Pulls newer image versions and recreates the containers with them — this is how you update NocoDB |
Common Errors
"docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?" — almost always means nesting wasn't enabled before the container started, or was enabled but the container was never restarted afterward. Stop the container, confirm nesting is checked under Options → Features, and start it again.
"Bind for 0.0.0.0:8080 failed: port is already allocated" — something else in the container is already using port 8080, usually a leftover NocoDB container from a previous failed attempt. Run docker ps -a, remove the stale container with docker rm -f <name>, and re-run the install script.
curl: (6) Could not resolve host — the container has no working DNS. Check that it actually has an IP (ip a) and that /etc/resolv.conf points to a reachable nameserver, usually your router or Pi-hole if you're running one.
The page loads but keeps disconnecting or spinning — this is almost always a websocket problem, not a NocoDB problem. It shows up when you put NocoDB behind a reverse proxy that isn't configured to forward websocket upgrade headers. See the troubleshooting section below.
Troubleshooting
If Docker itself refuses to start even with nesting enabled, it's usually one of two things. First, double-check the container was actually restarted after you flipped the nesting setting — changing it on a running container doesn't apply retroactively. Second, on some kernel and storage combinations, Docker's default overlay2 storage driver doesn't play well inside an unprivileged container. If you've confirmed nesting is on and Docker still won't come up, converting the container to privileged (uncheck "Unprivileged container" when creating it, or recreate it) is a reasonable fallback. You lose some of the isolation an unprivileged container gives you, but for a container that only runs Docker and nothing else, that's a trade a lot of homelab users make without much hesitation.
If NocoDB starts but you can't reach it from another machine, check the container's firewall first — Debian 13's default install doesn't enable one, but if you've hardened the container yourself, confirm port 8080 is allowed. Also confirm you're using the container's IP, not the Proxmox host's IP; it's an easy mix-up when you've got several tabs open.
Behind a reverse proxy, NocoDB needs the Upgrade and Connection headers forwarded and HTTP/1.1 used for the upstream connection, since it relies on websockets for live updates. In Nginx terms, that means setting proxy_http_version 1.1; along with proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade"; on the location block. Skip this and the UI will load but feel broken — data doesn't refresh, and you'll see repeated reconnect attempts in the browser console.
Best Practices
Back up the whole container with Proxmox's built-in backup tool (vzdump, or a scheduled backup job in the GUI) rather than trying to back up the Docker volumes individually. Since everything — Postgres data included — lives inside the container's root filesystem, a normal container backup captures all of it in one shot.
Take a snapshot before you run docker compose pull to update. Upgrades are usually painless, but a snapshot means a bad update costs you a rollback instead of a bad afternoon.
Don't expose port 8080 directly to the internet. If you want to access NocoDB away from home, put it behind a reverse proxy with a real TLS certificate, or reach it over something like Tailscale or WireGuard instead. An unauthenticated database editor sitting open on the public internet is exactly the kind of thing that gets found and probed within days.
Resize if you need to. 2 GB of RAM is a sensible starting point, but if you end up with dozens of tables and several people using it at once, bump the container to 4 GB rather than fighting sluggish performance.
Frequently Asked Questions
Does NocoDB replace my existing MySQL or Postgres database?
No. It connects to a database and gives you a spreadsheet interface on top of it. In this guide, that database is the Postgres instance the quick-install script sets up for you automatically.
Can I run NocoDB without Docker?
Yes, NocoDB also ships as a standalone Node.js application, but Docker is the officially recommended path and the one their install script targets, so it's the simpler route inside an LXC container.
Do I need a privileged container to run Docker?
No — an unprivileged container works fine once you enable the nesting and keyctl features. Privileged is only a fallback if you hit the storage driver issue mentioned in the troubleshooting section.
How much data can NocoDB realistically handle?
It scales with whatever Postgres can handle, which for a homelab use case is effectively unlimited. You'll hit "this UI is getting unwieldy" long before you hit any real database limit.
Is there a mobile app?
Not a native one. The web interface is responsive and usable on a phone browser, but there's no dedicated iOS or Android app as of this writing.
What happens if I lose the container?
You lose your data, unless you've backed it up. This is exactly why the Best Practices section above isn't optional — treat the backup step as part of the install, not something to get to later.
Conclusion
You've now got a self-hosted spreadsheet-database running in its own container, isolated from the rest of your homelab, with an upgrade path that's just two Docker commands. It's a small investment for something that ends up quietly running half your side projects once you start using it.
From here, the natural next steps are setting up that reverse proxy if you want access from outside your LAN, and scheduling a regular backup job for the container so an update gone wrong or a failed disk doesn't take your data with it.