SPCBotSPCBot Docs

FAQ

Learn how faq work in SPCBot and how to configure them for your team.

Visual Guide

Drop real screenshots into the paths below. This grid is rendered by src/app/docs/components/image-placeholder.tsx.

Dashboard Overview

Main dashboard with stats and recent deployments

public/docs/images/dashboard-overview.png

Server List

Connected servers and their health status

public/docs/images/servers-list.png

Deployment View

Live deployment logs and progress

public/docs/images/deployment-view.png

Answers to the questions we hear most before, and right after, a team starts using SPCBot.

What is SPCBot?

SPCBot is a dashboard for deploying and running Odoo. You connect a Git repository, pick a server, and click deploy — SPCBot handles the Docker configuration, the database, the domain and SSL certificate, and every redeploy after that. It replaces the usual pile of manual SSH sessions and hand-written scripts a growing Odoo setup accumulates with one place to see and operate every instance.

It is Odoo-native rather than a generic hosting panel: it understands Odoo versions and editions, odoo.conf, the filestore, addon repositories, and module upgrades — so a deploy only touches what actually changed instead of rebuilding everything from scratch every time.

Where does my data live?

Your servers, your data, any provider

SPCBot deploys to servers you register and own — a VPS at any provider, or your own hardware. SPCBot connects to it over SSH to manage Docker; it does not host your Odoo databases or filestores itself. If you ever stop using SPCBot, your data stays exactly where it already was.

SPCBot itself only stores the control-plane information needed to operate your environments: server connection details (encrypted), deployment history, backup indexes, and configuration. Credentials — SSH keys, database passwords, Git tokens — are encrypted at rest and are never displayed back in plain text after they're saved.

Which Odoo versions and editions are supported?

Every Odoo version from 13.0 through 19.0, both Community and Enterprise. Community and Enterprise run the same Docker image — Enterprise simply mounts an additional folder of Enterprise addon code — so switching an environment between editions, or running one of each side by side in the same project, is a configuration choice rather than a different deployment path.

Who can do what? (Roles)

Every organization has four roles. A role is the default for everything in the organization; on top of that, an Owner or Admin can hand a Developer (or, for a couple of narrow cases, a Viewer) an extra permission for one specific project or environment without changing their role.

RoleSeesDeploy / restart / manage environmentsManage servers & projectsWeb shell into an environmentPromote code to ProductionManage team & org settings
OwnerEverythingYesYesAlwaysAlwaysYes — full control, including other Admins
AdminEverything, unless scoped down to specific projects/serversYesYesYes, unless an Owner has revoked it for themYes, unless an Owner has revoked it for themYes — but cannot change or remove another Admin, and cannot create a new Owner
DeveloperOnly the projects and environments they have been given access to — nothing until an Owner or Admin grants itYesView only — cannot register a server or create a projectOnly on a project/environment an Admin or Owner has explicitly granted it forAutomatic for non-production environments; Production requires an explicit grantNo
ViewerOnly what they have been granted, read-only — nothing until an Owner or Admin grants itNoNoNeverNeverNo

A couple of details worth knowing: web shell access and branch promotion are handled as individually grantable permissions, not just role defaults — so an Admin can, for example, let one trusted Developer promote to Production without making them an Admin. A Viewer can never be granted shell access or promotion rights; those always require at least a Developer role.

How do I connect my code?

For GitHub, connect once per organization with a single click — no personal access token to create or paste. That one connection covers every repository the organization uses. For GitLab, Bitbucket, or a self-hosted Git server, a personal access token still works exactly as before.

What happens when I push code?

Push to your connected branch and SPCBot deploys automatically. What happens next depends on what changed:

  • Code-only change (no new or updated module needs a database migration): SPCBot builds the new version alongside the running one, health-checks it, and switches traffic over — visitors don't see a gap.
  • A change that migrates a module's data model: Odoo has to run its upgrade against the live database, which means a short downtime window while it does. This is a limitation of how Odoo migrations work, not something SPCBot works around — we would rather say so plainly than promise zero-downtime for every kind of deploy. SPCBot takes an automatic backup immediately before this kind of upgrade runs, specifically so there is something to restore if the migration itself fails.

You can also promote a branch from one environment to the next — development to staging to production — directly from the dashboard, instead of managing merges by hand.

What about backups and disaster recovery?

Backups are encrypted, scheduled per environment, and can be sent to your own cloud storage (S3-compatible, Google Cloud Storage, or another server you own) in addition to, or instead of, the server the environment runs on. Restoring takes an automatic safety snapshot of the target first, so a restore itself can be undone.

Point-in-time recovery lets you roll a database back to almost any second in its recent history, not just to the last scheduled backup — useful for undoing a bad data change without losing everything that happened afterward. Two honest limits: point-in-time recovery covers the database only (a full file restore is what you'd use to also roll back the filestore), and it is currently available for databases SPCBot runs itself, not ones hosted on an external, self-managed database service.

What's the browser editor?

A full code editor for your addon repositories, right in the browser — open a project, edit, and use an integrated terminal, with nothing to install locally. It runs in its own isolated container with its own network, completely separate from the environment's live database and its Odoo container — editing code there cannot reach or affect the running instance's data. Changes still go through Git and a normal deploy, the same as any other change.

How is my instance monitored?

Every server and environment gets CPU, memory, and disk charts out of the box, with no setup step — and if you already run your own Prometheus/Grafana stack on a server, you can switch to that instead. Alerts (resource thresholds, a deploy failing, a certificate about to expire, a backup that didn't complete) go to email by default, with Slack, Telegram, Discord, or a generic webhook available per organization, and every alert also shows up in-app regardless of whether any of those are configured.

Is SPCBot secure?

A few of the things that matter most:

  • Credentials are encrypted at rest. SSH keys, database passwords, and Git tokens are stored encrypted and are never shown back in plain text once saved.
  • Server connections are pinned. The first time SPCBot connects to a server it remembers that server's SSH host key, and every later connection is checked against it — so a connection that suddenly presents a different key is refused rather than silently trusted.
  • Every action is audited. Deploys, restarts, backups, restores, shell sessions, and administrative changes are all recorded with who did them and when, visible to an organization's Owners and Admins.
  • Two-factor authentication is available for every account, and organization membership, roles, and per-resource grants determine what any given user can see or do — enforced on the server, not just hidden in the interface.

Can I access Odoo's own database manager?

Odoo ships with its own built-in database manager screen, which can create, duplicate, or delete any database on an instance using only that instance's master password. Because of how powerful that screen is, SPCBot keeps it switched off by default on every environment.

If an Owner or Admin genuinely needs it — to duplicate a database for testing, or to hand-restore a dump — they can open it for a short, chosen window directly from the environment's settings. It closes itself automatically once that window ends, so there's no separate step to remember, and every time it's opened or closed is recorded in the organization's activity log.

Can I bring an existing Odoo instance under SPCBot?

Yes — SPCBot can adopt a pre-existing, already-running Odoo instance in place, on the same server, with the same domain and data, without a fresh deploy or any downtime beyond a brief cutover. It's designed for teams who already have Odoo running somewhere and want it under the same dashboard as everything else, rather than starting over.