I’m planning on running Companion as a standalone server for a web service that will have spiky traffic.
Hi, in our experience Companion will saturate network interface cards before other resources on commodity virtual servers (c5d.2xlarge for instance). Depending on your traffic you may find you can handle all customers on a single instance and only want to add a second for redundancy purposes. As an example for scale, one oss enterprise customer of ours that self-hosts Companion to power an education service that is deployed by virtually all universities globally, deploys 7 Companion instances, their previous solution ran on 35 instances I believe.
But as always it depends and your mileage may vary, so we recommend to add observability. You can let Prometheus crawl the /metrics endpoint and graph that with Grafana for instance.
For logging we follow The twelve-factor app is a methodology. Companion writes log entries to stdio, and the process that starts Companion decides where to stream those. For instance you could let Systemd start it, and direct the output to Splunk or other centralized logging solutions.
State is distributed and tied to processes with Companion so it is important to deploy sticky sessions. This can be done by giving Uppy clients URLs to specific hosts in their companion_url settings, or letting a layer 7 loadbalancer handle this by adding cookies to requests (e.g. on Kubernetes this could be handled with: Sticky Sessions - NGINX Ingress Controller). Update: we are moving away from this requirement.
General assistance is available through this community forum, if you need anything deeper, or to power anything mission critical, you may want to consider leveraging Transloadit’s hosted Companion servers (that we already scale and monitor globally this way and for which commercial support is included with any paid Plan starting at $49/mo), or our commercial open source plans in case self-hosting is a requirement for your use case.