FAQ

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?

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 ships on the list, 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.

The list itself is editable by a platform administrator in Settings → Odoo Versions: rows can be added, edited, reordered, or deactivated so they no longer appear when someone creates a project. Each row carries the Docker image tag that environments on that version pull on their next deploy.

Can I run older versions, such as Odoo 11 or 12?

Yes — nothing blocks a version below 13. Official odoo:11.0 and odoo:12.0 images exist, the generated odoo.conf already uses the older longpolling_port setting for them, and deploys, backups, restores, the shell and monitoring do not care which version is running. Add the row in Settings → Odoo Versions and it appears everywhere a version is chosen.

Both were tested with the configuration this platform generates: Odoo 12.0 on PostgreSQL 11 and Odoo 11.0 on PostgreSQL 10 each created their database and served the login page normally.

Which PostgreSQL version should I use with which Odoo?

Odoo's own guidance, and what to follow when in doubt. Choosing a database newer than your Odoo version supports is the risky direction: it usually starts, then fails later on a migration or a query written for the older engine.

Odoo version	PostgreSQL
11.0 – 12.0	9.5 – 11
13.0 – 15.0	10 – 13 (15.0 also runs on 14)
16.0	12 – 15
17.0	12 – 16
18.0 – 19.0	13 – 17

The platform default is PostgreSQL 15, which suits Odoo 13 through 19. The version is chosen per environment and cannot be changed afterwards — PostgreSQL refuses to start against data written by a different major version, so moving an environment to another major version means a dump and restore. For an external or already-installed database, the recorded version is informational; the provider or the installed server decides the real engine.

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.

Role	Sees	Deploy / restart / manage environments	Manage servers & projects	Web shell into an environment	Promote code to Production	Manage team & org settings
Owner	Everything	Yes	Yes	Always	Always	Yes — full control, including other Admins
Admin	Everything, unless scoped down to specific projects/servers	Yes	Yes	Yes, unless an Owner has revoked it for them	Yes, unless an Owner has revoked it for them	Yes — but cannot change or remove another Admin, and cannot create a new Owner
Developer	Only the projects and environments they have been given access to — nothing until an Owner or Admin grants it	Yes	View only — cannot register a server or create a project	Only on a project/environment an Admin or Owner has explicitly granted it for	Automatic for non-production environments; Production requires an explicit grant	No
Viewer	Only what they have been granted, read-only — nothing until an Owner or Admin grants it	No	No	Never	Never	No

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:

• Python method code only (logic inside a method, a new method, an import): no module upgrade is needed. SPCBot starts the new version alongside the running one, health-checks it, and switches traffic over — visitors don't see a gap.
• A change Odoo has to apply to the database (a field or model setting, a view, menu, security rule, data file or translation): SPCBot upgrades only the modules that changed. The upgrade normally runs while the current version keeps serving, then traffic switches to the new version. A very large upgrade (dozens of modules at once) runs with Odoo briefly stopped instead, because it would collide with live use.

Before any upgrade SPCBot records a rollback point — an instant point-in-time marker when point-in-time recovery is on, otherwise a backup kept on your server — and restores it automatically if the upgrade fails. The deploy log says which modules were upgraded or only restarted, and why.

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's the difference between Stop, Restart, Quick Update, and Deploy?

Stop/Start only turn the Odoo container off and on — the database keeps running, and nothing about the code changes. Restart reloads whatever code is already on the server (a few seconds of downtime) but downloads nothing and upgrades no modules, so it's only enough for a plain Python logic change.

Quick Update downloads the latest code for the project and every addon branch the environment uses, works out which modules actually changed for that environment's own database, and upgrades only those — normally while the site keeps serving requests, restarting only if something changed. Deploy does everything Quick Update does, plus it regenerates the Docker/Odoo/nginx configuration, pulls a fresh image, and installs any new Python dependencies — use it whenever a plain code/module upgrade isn't the whole change. The full breakdown and a comparison table are on the Instances page, under “Environment actions: Stop, Start, Restart, Quick Update, Deploy.”

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.