Skip to main content

Operating on BYOS

Once your server is connected, day-to-day work looks just like managed hosting. This page covers the areas where running on your own server behaves differently: domains and SSL, Odoo Enterprise, backups, and subscription behavior.

Domains and SSL​

Deployments on your own server do not receive automatic *.skysize.io addresses; those are reserved for managed cloud hosting. To reach a BYOS deployment over the web, you bring your own domain.

Without a domain​

A deployment without a domain is still reachable for testing at http://<your-server>:<port>, using the server's address and the port assigned to the branch. The dashboard shows the exact URL on the deployment. This is plain HTTP and best kept for internal verification, not end users.

Adding your domain​

  1. Open the branch's Domains section and add your domain (for example erp.mycompany.com), leaving SSL enabled.
  2. At your DNS provider, create an A record pointing the domain at your server's public IPv4 address (shown on the server's detail page in the dashboard).
  3. Wait for DNS to propagate, then open the domain in a browser.
note

On managed hosting you point a CNAME at your *.skysize.io hostname. On BYOS there is no such hostname, so you point an A record directly at your server's IP instead. The rest of the custom domain guide applies unchanged.

SSL certificates​

HTTPS certificates for BYOS deployments are issued on your server via Let's Encrypt, and renewed there automatically. Skysize's own platform certificates are never installed on customer hardware.

For issuance to succeed:

  • The domain's DNS must already resolve to your server.
  • Ports 80 and 443 on the server must be reachable from the internet (Let's Encrypt validates the domain over HTTP).

Until the certificate is issued, the site may briefly be reachable over HTTP only.

Odoo Enterprise on your own server​

Enterprise deployments on your server download the Odoo Enterprise source code using your own GitHub credentials, from your own Odoo Enterprise subscription. Skysize's enterprise credentials are never used on customer hardware.

To configure it, open your server's detail page and find the Odoo Enterprise source settings:

  • GitHub token: a personal access token of a GitHub account linked to your Odoo Enterprise subscription. It is stored encrypted and never shown again after saving.
  • Repository URL: leave empty to use the official odoo/enterprise repository, or set your own mirror (must start with https://).

You can also provide the token while creating an Enterprise project; the dashboard asks for it only when the target server has none configured yet.

caution

Without a valid token, Enterprise builds on that server fail because the enterprise code cannot be downloaded. Community projects are unaffected.

Workers and memory​

Your server, your sizing: on BYOS the deployment's worker count is not sold by the plan, you choose it. Open the project's Settings and go to Workers and memory. These settings size the production deployment only; staging and development deployments always run as a single Odoo process on fixed resources.

  • Workers: the number of Odoo HTTP worker processes. Leave it at 0 for a single process that serves HTTP and scheduled actions together, which is the right choice for a small instance or a modest server. Set 2 or more to run Odoo in multiprocess mode, where each worker handles requests in parallel.
  • Cron workers: how many processes run scheduled actions. Only used in multiprocess mode; Odoo's default is 2.
  • Memory per worker: the hard memory ceiling of each Odoo process, in MB. The minimum is 512 MB and the default is 1024 MB. A process that exceeds it is restarted by Odoo, so raise it if your workload handles large imports or reports.

When you change any of these, the dashboard shows the maximum RAM the deployment may use before you apply: every process at its memory ceiling, plus 512 MB of headroom for the container. Check that your server has that much memory available, on top of Postgres and anything else it runs.

Apply and restart saves the sizing and restarts the production deployment, so expect a short interruption.

note

The Request timeout and Cron worker timeout settings live in the same section and behave exactly as on managed hosting. See Time Limits.

Backups​

The full backup system works on BYOS: automatic daily backups of production, manual backups, restores, downloads, and imports. Backup jobs run on your server, then upload the archive to the project's configured storage target.

Choosing where backups are stored​

BYOS projects back up to your own storage: Skysize's platform storage is not offered as a target, so both the live data (on your server) and the backups stay on infrastructure you control. Until you configure a target, no backups are made, and the project shows a red banner saying so.

  1. Open the project's Settings and go to Backup Target.
  2. Under Your backup targets, click Add Target and create a target of type Filesystem, AWS S3, or Google Cloud Storage (see the examples below). Use Test to verify the connection.
  3. The first target you add is selected as the project's Storage target automatically. If you add more later, pick the one to use under Storage target and save.

Configuration examples​

A backup target has a name, a type, and a Configuration (JSON) field whose settings depend on the type. The configuration is stored encrypted; credentials never appear in plain text again after saving. One example per type:

Filesystem​

Writes archives to a directory on the server itself:

{
    "base_path": "/var/lib/skysize/backups"
}

base_path is optional and defaults to /var/lib/skysize/backups.

caution

Filesystem backups live on the same machine as your databases. They protect against bad data (accidental deletions, failed upgrades) but not against losing the server itself. For disaster recovery, use an S3 or Google Cloud Storage target, or copy the backup directory off the server yourself.

AWS S3​

Uploads archives to an S3 bucket:

{
    "bucket": "mycompany-odoo-backups",
    "region": "eu-central-1",
    "prefix": "erp-production",
    "access_key_id": "AKIAIOSFODNN7EXAMPLE",
    "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

bucket is required; region defaults to us-east-1 when omitted. prefix is optional and places every archive under that key prefix, which is useful when several projects share one bucket.

access_key_id and secret_access_key are optional. When they are omitted, the agent uses the credentials of the machine it runs on (the AWS default credential chain). If your server is an EC2 instance, this is the recommended setup: attach an IAM role to the instance and leave both keys out, so no long-lived secret is stored anywhere and rotation is handled by AWS:

{
    "bucket": "mycompany-odoo-backups",
    "region": "eu-central-1",
    "prefix": "erp-production"
}

Whether you use an instance role or an access key, the identity must be allowed to list the bucket and to put, get, and delete objects in it. A minimal policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
            "Resource": "arn:aws:s3:::mycompany-odoo-backups"
        },
        {
            "Effect": "Allow",
            "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts"],
            "Resource": "arn:aws:s3:::mycompany-odoo-backups/*"
        }
    ]
}

Use an access key only when the server does not run on AWS (create an IAM user with the policy above, then Security credentials → Create access key). The Test button runs the check from your server itself, so it validates the instance role the same way a real backup would.

Google Cloud Storage​

Uploads archives to a GCS bucket:

{
    "bucket": "mycompany-odoo-backups",
    "prefix": "erp-production",
    "credentials_json": "{\"type\": \"service_account\", \"project_id\": \"my-project\", \"private_key_id\": \"...\", \"private_key\": \"...\", \"client_email\": \"[email protected]\", ...}"
}

bucket is required; prefix is optional, as for S3. credentials_json is the full content of a service-account key file, embedded as a single JSON string (quotes escaped). The service account needs the Storage Object Admin role on the bucket. If you leave credentials_json empty, the agent falls back to the machine's default Google credentials, which usually only exist when your server runs on Google Cloud.

tip

Backups are created on the server before upload, so keep enough free disk space for a compressed copy of your largest database plus its filestore.

If your subscription lapses​

If your Bring Your Own Server subscription expires or is cancelled, Skysize never reaches into your server to shut anything down:

  • Running deployments keep running. Your Odoo instances and their data stay up on your hardware.
  • New work is blocked. Builds, deployments, and backups for BYOS projects are refused until the subscription is active again, and new servers or BYOS projects cannot be added. The affected projects show a banner in the dashboard.
  • Renewing restores everything. Renew or repurchase the subscription from the Agents page and builds and backups resume; no reinstallation is needed.
caution

If the account remains without any active Bring Your Own Server subscription for an extended period (about 30 days), connected servers that are not hosting deployments of active projects are removed from the dashboard. You would need to register and enroll them again after resubscribing. Servers still hosting your running deployments are not removed.

Limits and differences vs cloud hosting​

  • No *.skysize.io domains. Every deployment you want to reach over the web needs your own domain, with an A record pointed at your server.
  • No Cloudflare proxy toggle. Traffic goes straight to your server. If you want a CDN or DDoS protection in front of it, configure that at your own DNS or proxy provider.
  • No region selection. Your server's location is the region. Latency and data residency are determined by where you host it.
  • No free tier. BYOS projects always require an active Bring Your Own Server subscription, one per project.
  • Capacity is yours to manage. CPU, RAM, and disk are limited by your hardware. Watch the server's metrics in the dashboard and add resources, or connect additional servers, before they run out. With multiple servers, production runs on the server you selected and other branches balance across all of them.
  • Server maintenance is yours. Operating system updates, security patching, and firewall configuration of the machine are your responsibility. Skysize keeps the agent and your Odoo deployments up to date.

Everything else, including branch workflows, build logs, access management, and restores, behaves exactly as on managed hosting.