juxtaboard
Start free

Self-hosting guide

Run Juxtaboard on your own server, and bring your project with you

The Juxtaboard server is a Docker bundle. One command installs it, automatic HTTPS included. Your project moves across as a single export: tables, rows, documents, forms, dashboards, files, portal users and automations. About an hour end to end, most of it waiting for downloads.

Free to run in production and commercially. See the licence in short and the support plans.

Before you start

  • A Linux server with x86_64 (amd64) CPU, root or sudo access, at least 2 vCPU, 4 GB RAM and 30 GB of disk. Docker with the Compose plugin installed.
  • A domain you control, such as docs.example.com, with an A record pointing at the server. Ports 80 and 443 open (also in your provider's firewall).
  • Owner access to the cloud project you want to move.
  • Optional: SMTP credentials, so the new server can send sign-in links.

  1. 1Download the release

    The newest release is always described in latest.json. Download it, check the checksum, unpack.

    mkdir -p ~/juxtaboard && cd ~/juxtaboard
curl -fsS https://downloads.juxtaboard.com/latest.json -o latest.json
curl -fL -C - -o release.tar "$(jq -r .url latest.json)"
echo "$(jq -r .sha256 latest.json)  release.tar" | sha256sum -c -
tar xf release.tar && cd codedocs-*/

    The checksum line must print release.tar: OK. The archive is about 640 MB.

  2. 2Install with one command

    ./install.sh --domain docs.example.com

    The script loads the image, generates your secrets, starts the app with its database and cache, and asks Caddy to obtain a Let's Encrypt certificate. The first start applies database migrations, so give it a few minutes. At the end it prints the admin login and password.

    Copy the .env file off the server now. It holds the keys that unlock your data. Lose it and saved connector credentials become unreadable.

  3. 3Sign in and prepare the target

    Open https://docs.example.com, sign in as admin and change the password. Then create an empty project with the same name as the one you are moving.

  4. 4Connect your coding agent

    Skip this step if you will move the project by hand. Otherwise, connect your agent to both servers over MCP. Each server's MCP address is its own address plus /api/mcp. Sign-in uses OAuth, so you don't copy any tokens. In Claude Code:

    claude mcp add --transport http juxtaboard-cloud https://juxtaboard.com/api/mcp
claude mcp add --transport http juxtaboard-server https://docs.example.com/api/mcp

    Then run /mcp in Claude Code and choose Authenticate for each server. A browser window opens. Sign in, then on the authorization screen:

    • Which projects to grant access to: All my projects, or the project you are moving.
    • Access level: Admin access (mcp:admin). Moving a project changes its settings, groups and access rules, which need admin access. It is offered for all-projects grants and for projects you own.

    Click Approve. Codex, Cursor and other agents that support MCP over HTTP with OAuth work the same way: add the address, then sign in when the agent asks.

  5. 5Move the project

    The easy way: with your agent connected to both servers (step 4), ask:

    Set up my Juxtaboard on my server and move my project to it.

    The agent follows the built-in self-hosting runbook: it takes a restore point of the cloud project, exports it, previews the import, applies it, and reports what moved. It asks before every change to your server and never touches the cloud copy.

    By hand: in the cloud project open Export / Import, export the workspace with rows, then import that file into the empty project on your server.

  6. 6Check it, then switch things on

    • Compare the numbers: documents, rows per table, views, users. They should match the cloud project.
    • Automations and connectors arrive switched off. That is deliberate, so nothing runs on both servers at once. Review each one, set outgoing mail in .env if you need it, then enable them.
    • Team members sign in on the new server with their own accounts: invite them again. Portal users, groups and access grants are carried over.
    • Webhooks, OAuth redirect addresses and payment callbacks that point at the cloud address must be updated to the new domain.

  7. 7Point your front end at the new server

    Your app's own code stays where it is. Change the Juxtaboard address in it from the cloud to https://docs.example.com and add your app's address to the project's allowed origins on the new server. Deploy, test sign-in and a few actions, and keep the cloud project untouched until you are happy. That is your way back.

Good to know

  • Upgrading later means running the same steps with a newer release. Your data volumes stay.
  • The image is built for x86_64. There is no ARM build yet.
  • You can run a trial first: ./install.sh --port 3100 starts a local copy at http://localhost:3100, no domain needed.
  • We moved our four demo projects this way, rows and files included.

Prefer us to run it?

Start free in the cloud, and move whenever you like. Nothing is locked in.

Start free ↗ Self-hosting support plans →