openvibers/openvibe.live OVH.md
OVH.md
| 1 | # OVH Public Cloud Sizing Guide for OpenVibe.Live |
| 2 | |
| 3 | This document compares the OVH Public Cloud plans you listed for running OpenVibe.Live, with a focus on: |
| 4 | |
| 5 | - single-server deployment economics |
| 6 | - storage for VODs, clips, thumbnails, and app data |
| 7 | - live streaming up to roughly 200 concurrent viewers |
| 8 | - tradeoffs between **WebRTC**, **JSMPEG**, and **RTMP** delivery paths |
| 9 | - how far the OVH **$200 / 90-day** public-cloud credit goes |
| 10 | |
| 11 | The analysis assumes the current OpenVibe.Live architecture in [server/index.js](server/index.js) and [server/config.js](server/config.js), where the application can expose: |
| 12 | |
| 13 | - the main Node/Express app on `3000` |
| 14 | - WebSocket services |
| 15 | - RTMP ingest |
| 16 | - JSMPEG relay ports |
| 17 | - optional WebRTC / `mediasoup` |
| 18 | - local VOD / clip / thumbnail / emote / avatar storage under `data/` |
| 19 | |
| 20 | --- |
| 21 | |
| 22 | ## Executive summary |
| 23 | |
| 24 | ### Best overall pick |
| 25 | |
| 26 | If you want **one OVH instance that makes the most sense for real OpenVibe.Live production**, the best all-around choice from the list is: |
| 27 | |
| 28 | - **B3-32** |
| 29 | |
| 30 | Why: |
| 31 | |
| 32 | - 32 GB RAM is enough for Node, PostgreSQL, WebSockets, chat, thumbnails, clips, and moderate media workload |
| 33 | - 8 vCores is a sane floor for a mixed single-box deployment |
| 34 | - 200 GB NVMe is much more realistic than 50–100 GB once VODs and clips start accumulating |
| 35 | - 2 Gbit/s leaves real headroom for 200 viewers at practical streaming bitrates |
| 36 | - the price jump from `B3-16` to `B3-32` is small compared with the gain in RAM, bandwidth, and storage |
| 37 | |
| 38 | ### Best budget / staging pick |
| 39 | |
| 40 | - **B3-8** if you want the cheapest decent general-purpose box |
| 41 | - **C3-8** if you want a cheaper CPU-heavier test box and do not care about having only 100 GB storage |
| 42 | |
| 43 | ### Best safer production pick for 200-viewer WebRTC-heavy usage |
| 44 | |
| 45 | - **B3-64** |
| 46 | |
| 47 | Why: |
| 48 | |
| 49 | - 16 vCores is a much healthier place to be if you expect 200 viewers with more WebRTC usage, call features, game traffic, clip creation, and multiple real-time subsystems running at once |
| 50 | - 4 Gbit/s helps if your viewer bitrate climbs or you have more than one stream / camera / room pattern later |
| 51 | |
| 52 | ### Families that make the least sense here |
| 53 | |
| 54 | For OpenVibe.Live, the **older B2** and **older C2** families mostly lose on price/performance against the new **B3** and **C3** families. |
| 55 | |
| 56 | In practice: |
| 57 | |
| 58 | - **B3 beats B2** for most balanced OpenVibe.Live use |
| 59 | - **B3 or B3-64 often beats C3 as well**, unless you are extremely CPU-centric and can live with less storage / bandwidth for the money |
| 60 | - **C2** is the least attractive family in this list for this workload |
| 61 | |
| 62 | --- |
| 63 | |
| 64 | ## 1. What actually limits OpenVibe.Live on a single OVH instance |
| 65 | |
| 66 | For OpenVibe.Live, the bottleneck is not just RAM. |
| 67 | |
| 68 | The main constraints are: |
| 69 | |
| 70 | 1. **Outbound bandwidth** |
| 71 | 2. **CPU** |
| 72 | 3. **Disk space** |
| 73 | 4. **Disk I/O** |
| 74 | 5. **Operational headroom** for Node, FFmpeg, thumbnails, clips, chat, and WebSockets |
| 75 | |
| 76 | ### Outbound bandwidth is the first hard wall |
| 77 | |
| 78 | For all three playback methods, if the origin server is doing the actual delivery, your OVH network cap matters a lot: |
| 79 | |
| 80 | - **JSMPEG**: the server relays the live stream to every viewer |
| 81 | - **RTMP playback / HTTP-FLV style delivery**: the server still pays outbound bandwidth per viewer |
| 82 | - **WebRTC SFU**: the server forwards media to each viewer; outbound still scales with audience size |
| 83 | |
| 84 | Cloudflare can protect the website and proxied HTTP traffic, but **raw media ports and direct real-time traffic are not magically offloaded** just because the website uses Cloudflare. |
| 85 | |
| 86 | ### CPU becomes more important for WebRTC than for simple relay paths |
| 87 | |
| 88 | Relative server-side cost, roughly: |
| 89 | |
| 90 | - **JSMPEG**: usually more bandwidth-bound than CPU-bound on the server side |
| 91 | - **RTMP ingest + direct playback**: also heavily bandwidth-bound |
| 92 | - **WebRTC / mediasoup**: usually more CPU-sensitive because of SFU packet forwarding, transport handling, encryption overhead, and more real-time state |
| 93 | |
| 94 | ### Storage dominates once VODs are enabled |
| 95 | |
| 96 | The current codebase stores locally: |
| 97 | |
| 98 | - PostgreSQL database |
| 99 | - VODs |
| 100 | - clips |
| 101 | - thumbnails |
| 102 | - emotes |
| 103 | - avatars |
| 104 | - media assets |
| 105 | |
| 106 | The OS and app do not need much space. **Recorded video does.** |
| 107 | |
| 108 | --- |
| 109 | |
| 110 | ## 2. Simple bandwidth math for 200 viewers |
| 111 | |
| 112 | A useful first-order formula is: |
| 113 | |
| 114 | $$ |
| 115 | \text{required egress Mbps} \approx \text{viewer count} \times \text{average delivered Mbps per viewer} |
| 116 | $$ |
| 117 | |
| 118 | Examples for **200 viewers**: |
| 119 | |
| 120 | - at **1.5 Mbps** average delivered bitrate: about **300 Mbps** raw egress |
| 121 | - at **2.5 Mbps** average delivered bitrate: about **500 Mbps** raw egress |
| 122 | - at **4.0 Mbps** average delivered bitrate: about **800 Mbps** raw egress |
| 123 | |
| 124 | Real deployments need headroom for: |
| 125 | |
| 126 | - TLS / protocol overhead |
| 127 | - chat, API, thumbnails, clips, admin traffic |
| 128 | - bitrate spikes |
| 129 | - multiple tabs / reconnections / bursts |
| 130 | - FFmpeg, VOD, and background jobs |
| 131 | |
| 132 | So a safer planning rule is to target around **70% of the listed port speed** as usable sustained capacity. |
| 133 | |
| 134 | ### Practical safe viewer counts at 70% utilization |
| 135 | |
| 136 | The table below assumes one stream and one average delivered bitrate. |
| 137 | |
| 138 | | NIC cap | Safe usable Mbps | ~1.5 Mbps/viewer | ~2.5 Mbps/viewer | ~4.0 Mbps/viewer | |
| 139 | |---|---:|---:|---:|---:| |
| 140 | | 250 Mbit/s | 175 | 116 | 70 | 43 | |
| 141 | | 500 Mbit/s | 350 | 233 | 140 | 87 | |
| 142 | | 1,000 Mbit/s | 700 | 466 | 280 | 175 | |
| 143 | | 2,000 Mbit/s | 1400 | 933 | 560 | 350 | |
| 144 | | 4,000 Mbit/s | 2800 | 1866 | 1120 | 700 | |
| 145 | | 8,000 Mbit/s | 5600 | 3733 | 2240 | 1400 | |
| 146 | | 10,000 Mbit/s | 7000 | 4666 | 2800 | 1750 | |
| 147 | | 16,000 Mbit/s | 11200 | 7466 | 4480 | 2800 | |
| 148 | |
| 149 | ### What that means for 200 viewers |
| 150 | |
| 151 | If you want room for **200 real viewers**: |
| 152 | |
| 153 | - **250 Mbit/s plans** are not enough except maybe for very low bitrates and a soft audience ceiling |
| 154 | - **500 Mbit/s plans** can work for low-mid bitrate delivery, but they are not where I would want to be for a real 200-viewer goal |
| 155 | - **1 Gbit/s plans** are viable for 200 viewers if you keep average delivered bitrate moderate |
| 156 | - **2 Gbit/s plans** are where the setup gets comfortable |
| 157 | - **4 Gbit/s plans** are where you stop thinking about bandwidth first and start thinking more about CPU and storage |
| 158 | |
| 159 | --- |
| 160 | |
| 161 | ## 3. Storage math for VODs and clips |
| 162 | |
| 163 | A fast rule of thumb: |
| 164 | |
| 165 | $$ |
| 166 | 1\ \text{Mbps} \approx 0.44\ \text{GB/hour} |
| 167 | $$ |
| 168 | |
| 169 | So: |
| 170 | |
| 171 | - **1.5 Mbps** ≈ **0.66 GB/hour** |
| 172 | - **2.5 Mbps** ≈ **1.10 GB/hour** |
| 173 | - **4.0 Mbps** ≈ **1.76 GB/hour** |
| 174 | - **6.0 Mbps** ≈ **2.64 GB/hour** |
| 175 | |
| 176 | ### Why 50–100 GB fills quickly |
| 177 | |
| 178 | You should reserve space for: |
| 179 | |
| 180 | - Ubuntu + packages + logs |
| 181 | - app code |
| 182 | - PostgreSQL data |
| 183 | - thumbnails, avatars, emotes |
| 184 | - temporary files during clip/VOD work |
| 185 | |
| 186 | A practical reserve is roughly **15–25 GB**. |
| 187 | |
| 188 | That means usable recording space looks more like: |
| 189 | |
| 190 | | Raw disk | Rough usable media space after OS/app reserve | |
| 191 | |---|---:| |
| 192 | | 50 GB | 25–35 GB | |
| 193 | | 100 GB | 75–85 GB | |
| 194 | | 200 GB | 175–185 GB | |
| 195 | | 400 GB | 375–385 GB | |
| 196 | |
| 197 | ### Approximate retained recording hours |
| 198 | |
| 199 | At **2.5 Mbps** average recording bitrate: |
| 200 | |
| 201 | - 30 GB usable → about **27 hours** |
| 202 | - 80 GB usable → about **73 hours** |
| 203 | - 180 GB usable → about **164 hours** |
| 204 | - 380 GB usable → about **345 hours** |
| 205 | |
| 206 | At **4.0 Mbps** average recording bitrate: |
| 207 | |
| 208 | - 30 GB usable → about **17 hours** |
| 209 | - 80 GB usable → about **45 hours** |
| 210 | - 180 GB usable → about **102 hours** |
| 211 | - 380 GB usable → about **216 hours** |
| 212 | |
| 213 | ### Storage takeaway |
| 214 | |
| 215 | For OpenVibe.Live with VODs enabled: |
| 216 | |
| 217 | - **50 GB** is basically test-only |
| 218 | - **100 GB** is okay for dev / alpha / minimal retention |
| 219 | - **200 GB** is the first storage size that feels production-usable |
| 220 | - **400 GB** is much better, but still not archival scale if you keep lots of VODs |
| 221 | |
| 222 | If your VOD library matters, the right long-term answer is usually: |
| 223 | |
| 224 | - use local NVMe for active recordings and hot files |
| 225 | - push older VODs / archives to object storage or another storage layer later |
| 226 | |
| 227 | --- |
| 228 | |
| 229 | ## 4. Family-by-family analysis |
| 230 | |
| 231 | ## B3 family — best overall fit |
| 232 | |
| 233 | The new B3 family is the strongest match for OpenVibe.Live because it balances: |
| 234 | |
| 235 | - decent vCPU counts |
| 236 | - generous RAM |
| 237 | - NVMe storage |
| 238 | - strong network steps |
| 239 | - good pricing |
| 240 | |
| 241 | ### B3 plans |
| 242 | |
| 243 | | Plan | RAM | vCPU | Disk | NIC | Price/hour | |
| 244 | |---|---:|---:|---:|---:|---:| |
| 245 | | B3-8 | 8 GB | 2 | 50 GB NVMe | 500 Mbit/s | $0.0508 | |
| 246 | | B3-16 | 16 GB | 4 | 100 GB NVMe | 1,000 Mbit/s | $0.1016 | |
| 247 | | B3-32 | 32 GB | 8 | 200 GB NVMe | 2,000 Mbit/s | $0.2033 | |
| 248 | | B3-64 | 64 GB | 16 | 400 GB NVMe | 4,000 Mbit/s | $0.4065 | |
| 249 | | B3-128 | 128 GB | 32 | 400 GB NVMe | 8,000 Mbit/s | $0.8131 | |
| 250 | | B3-256 | 256 GB | 64 | 400 GB NVMe | 16,000 Mbit/s | $1.6262 | |
| 251 | |
| 252 | ### B3 conclusions |
| 253 | |
| 254 | - **B3-8**: good dev box, too small for serious 200-viewer ambitions |
| 255 | - **B3-16**: good small production / alpha / staging box |
| 256 | - **B3-32**: best overall single-box production choice |
| 257 | - **B3-64**: best safer serious production choice if you want 200 viewers with headroom |
| 258 | - **B3-128 / B3-256**: overkill for early OpenVibe.Live unless you are running much larger real-time workloads or multiple major streams/services on the same machine |
| 259 | |
| 260 | --- |
| 261 | |
| 262 | ## B2 family — older and mostly outclassed |
| 263 | |
| 264 | ### B2 plans |
| 265 | |
| 266 | | Plan | RAM | vCPU | Disk | NIC | Price | |
| 267 | |---|---:|---:|---:|---:|---:| |
| 268 | | B2-7 | 7 GB | 2 | 50 GB SSD | 250 Mbit/s | $29.04/mo or $0.0813/h | |
| 269 | | B2-15 | 15 GB | 4 | 100 GB SSD | 250 Mbit/s | $55.44/mo or $0.1539/h | |
| 270 | | B2-30 | 30 GB | 8 | 200 GB SSD | 500 Mbit/s | $112.20/mo or $0.3123/h | |
| 271 | | B2-60 | 60 GB | 16 | 400 GB SSD | 1,000 Mbit/s | $217.80/mo or $0.6060/h | |
| 272 | | B2-120 | 120 GB | 32 | 400 GB SSD | 10,000 Mbit/s | $429.00/mo or $1.1923/h | |
| 273 | |
| 274 | ### B2 conclusions |
| 275 | |
| 276 | Compared with B3, B2 generally gives you: |
| 277 | |
| 278 | - worse price/performance |
| 279 | - older SSD instead of NVMe |
| 280 | - weaker bandwidth at comparable sizes |
| 281 | |
| 282 | For OpenVibe.Live, I would only choose B2 if: |
| 283 | |
| 284 | - you specifically need that family for quota / availability / billing reasons |
| 285 | - B3 is unavailable in your chosen zone |
| 286 | |
| 287 | Otherwise B3 is better. |
| 288 | |
| 289 | --- |
| 290 | |
| 291 | ## C3 family — interesting for CPU-heavy real-time workloads, but not the best value here |
| 292 | |
| 293 | ### C3 plans |
| 294 | |
| 295 | | Plan | RAM | vCPU | Disk | NIC | Price/hour | |
| 296 | |---|---:|---:|---:|---:|---:| |
| 297 | | C3-4 | 4 GB | 2 | 50 GB NVMe | 250 Mbit/s | $0.0453 | |
| 298 | | C3-8 | 8 GB | 4 | 100 GB NVMe | 500 Mbit/s | $0.0907 | |
| 299 | | C3-16 | 16 GB | 8 | 200 GB NVMe | 1,000 Mbit/s | $0.1813 | |
| 300 | | C3-32 | 32 GB | 16 | 400 GB NVMe | 2,000 Mbit/s | $0.3627 | |
| 301 | | C3-64 | 64 GB | 32 | 400 GB NVMe | 4,000 Mbit/s | $0.7254 | |
| 302 | | C3-128 | 128 GB | 64 | 400 GB NVMe | 8,000 Mbit/s | $1.4508 | |
| 303 | |
| 304 | ### C3 conclusions |
| 305 | |
| 306 | C3 gets interesting if you believe the deployment will be heavily: |
| 307 | |
| 308 | - WebRTC-centric |
| 309 | - CPU-bound |
| 310 | - real-time packet / transport heavy |
| 311 | |
| 312 | But for OpenVibe.Live specifically, the B3 line still usually wins because the app is not a pure CPU benchmark. It is a mixed workload that also wants: |
| 313 | |
| 314 | - more RAM |
| 315 | - more bandwidth |
| 316 | - more storage |
| 317 | - better economics per box |
| 318 | |
| 319 | #### Example comparisons |
| 320 | |
| 321 | - **B3-32**: 32 GB / 8 vCPU / 200 GB / 2 Gbit/s for **$0.2033/h** |
| 322 | - **C3-16**: 16 GB / 8 vCPU / 200 GB / 1 Gbit/s for **$0.1813/h** |
| 323 | |
| 324 | For only a little more money, `B3-32` gives you: |
| 325 | |
| 326 | - double the RAM |
| 327 | - double the network |
| 328 | - same storage |
| 329 | - same vCPU count |
| 330 | |
| 331 | That is a better OpenVibe.Live trade most of the time. |
| 332 | |
| 333 | - **B3-64**: 64 GB / 16 vCPU / 400 GB / 4 Gbit/s for **$0.4065/h** |
| 334 | - **C3-32**: 32 GB / 16 vCPU / 400 GB / 2 Gbit/s for **$0.3627/h** |
| 335 | |
| 336 | Again, `B3-64` is only a bit more expensive while giving much more breathing room. |
| 337 | |
| 338 | --- |
| 339 | |
| 340 | ## C2 family — least attractive for this workload |
| 341 | |
| 342 | ### C2 plans |
| 343 | |
| 344 | | Plan | RAM | vCPU | Disk | NIC | Price | |
| 345 | |---|---:|---:|---:|---:|---:| |
| 346 | | C2-7 | 7 GB | 2 | 50 GB SSD | 250 Mbit/s | $42.24/mo or $0.1176/h | |
| 347 | | C2-15 | 15 GB | 4 | 100 GB SSD | 250 Mbit/s | $81.83/mo or $0.2276/h | |
| 348 | | C2-30 | 30 GB | 8 | 200 GB SSD | 500 Mbit/s | $165.00/mo or $0.4586/h | |
| 349 | | C2-60 | 60 GB | 16 | 400 GB SSD | 1,000 Mbit/s | $323.40/mo or $0.8986/h | |
| 350 | | C2-120 | 120 GB | 32 | 400 GB SSD | 10,000 Mbit/s | $640.20/mo or $1.7786/h | |
| 351 | |
| 352 | ### C2 conclusions |
| 353 | |
| 354 | C2 has higher listed GHz in this snapshot, but the family is much harder to justify because: |
| 355 | |
| 356 | - it is expensive |
| 357 | - it is older |
| 358 | - it still often has weaker bandwidth than the B3 alternative |
| 359 | - the storage type is not as appealing as NVMe on B3/C3 |
| 360 | |
| 361 | I would not choose C2 for OpenVibe.Live unless there were some very specific external reason. |
| 362 | |
| 363 | --- |
| 364 | |
| 365 | ## 5. Method-by-method plan fit |
| 366 | |
| 367 | ## WebRTC / mediasoup |
| 368 | |
| 369 | This is the method most likely to become **CPU-sensitive** first. |
| 370 | |
| 371 | ### Good choices |
| 372 | |
| 373 | - **B3-32** for moderate production |
| 374 | - **B3-64** for safer 200-viewer production |
| 375 | - **C3-32** only if you are convinced CPU will matter more than RAM/bandwidth economics |
| 376 | |
| 377 | ### Avoid for 200-viewer goals |
| 378 | |
| 379 | - `B3-8`, `B2-7`, `C3-4`, `C2-7` |
| 380 | |
| 381 | ### Practical recommendation |
| 382 | |
| 383 | If your expected audience is really up to 200 and WebRTC is a real primary path, I would start at **B3-64**, not because 32 GB RAM is required, but because the full balance of: |
| 384 | |
| 385 | - 16 vCores |
| 386 | - 4 Gbit/s |
| 387 | - 400 GB NVMe |
| 388 | |
| 389 | is much healthier. |
| 390 | |
| 391 | --- |
| 392 | |
| 393 | ## JSMPEG |
| 394 | |
| 395 | JSMPEG is typically more straightforward on the server side and becomes **bandwidth-bound** quickly. |
| 396 | |
| 397 | ### Good choices |
| 398 | |
| 399 | - **B3-16** for smaller audiences and testing |
| 400 | - **B3-32** for up to 200 viewers at moderate bitrates |
| 401 | - **B3-64** if you want bitrate headroom or larger audience spikes |
| 402 | |
| 403 | ### Practical recommendation |
| 404 | |
| 405 | For a JSMPEG-heavy public deployment, **B3-32** is the sweet spot. |
| 406 | |
| 407 | --- |
| 408 | |
| 409 | ## RTMP ingest + direct playback |
| 410 | |
| 411 | RTMP ingest itself is light. Viewer delivery is what costs you. |
| 412 | |
| 413 | If OpenVibe.Live is the box serving the live playback path, you again care most about: |
| 414 | |
| 415 | - outbound bandwidth |
| 416 | - storage if recording VODs |
| 417 | |
| 418 | ### Good choices |
| 419 | |
| 420 | - **B3-16** for low-mid audience counts |
| 421 | - **B3-32** for a real public rollout |
| 422 | - **B3-64** if you expect higher bitrate, spikes, or multiple simultaneous live loads |
| 423 | |
| 424 | ### Practical recommendation |
| 425 | |
| 426 | Again, **B3-32** is the best overall one-box answer. |
| 427 | |
| 428 | --- |
| 429 | |
| 430 | ## 6. $200 OVH credit analysis |
| 431 | |
| 432 | OVH gives **$200 in public cloud credit that expires after 90 days**. |
| 433 | |
| 434 | That means there are two important questions: |
| 435 | |
| 436 | 1. how long the credit lasts if you run continuously |
| 437 | 2. whether the plan can run the full 90 days within the credit window |
| 438 | |
| 439 | ### How long $200 lasts on each plan |
| 440 | |
| 441 | | Plan | Price/hour | $200 lasts | Hours | |
| 442 | |---|---:|---:|---:| |
| 443 | | B3-8 | $0.0508 | 164.04 days | 3937.0 h | |
| 444 | | B3-16 | $0.1016 | 82.02 days | 1968.5 h | |
| 445 | | B3-32 | $0.2033 | 40.99 days | 983.8 h | |
| 446 | | B3-64 | $0.4065 | 20.50 days | 492.0 h | |
| 447 | | B3-128 | $0.8131 | 10.25 days | 246.0 h | |
| 448 | | B3-256 | $1.6262 | 5.12 days | 123.0 h | |
| 449 | | B2-7 | $0.0813 | 102.50 days | 2460.0 h | |
| 450 | | B2-15 | $0.1539 | 54.15 days | 1299.5 h | |
| 451 | | B2-30 | $0.3123 | 26.68 days | 640.4 h | |
| 452 | | B2-60 | $0.6060 | 13.75 days | 330.0 h | |
| 453 | | B2-120 | $1.1923 | 6.99 days | 167.7 h | |
| 454 | | C3-4 | $0.0453 | 183.96 days | 4415.0 h | |
| 455 | | C3-8 | $0.0907 | 91.88 days | 2205.1 h | |
| 456 | | C3-16 | $0.1813 | 45.96 days | 1103.1 h | |
| 457 | | C3-32 | $0.3627 | 22.98 days | 551.4 h | |
| 458 | | C3-64 | $0.7254 | 11.49 days | 275.7 h | |
| 459 | | C3-128 | $1.4508 | 5.74 days | 137.9 h | |
| 460 | | C2-7 | $0.1176 | 70.86 days | 1700.7 h | |
| 461 | | C2-15 | $0.2276 | 36.61 days | 878.7 h | |
| 462 | | C2-30 | $0.4586 | 18.17 days | 436.1 h | |
| 463 | | C2-60 | $0.8986 | 9.27 days | 222.6 h | |
| 464 | | C2-120 | $1.7786 | 4.69 days | 112.4 h | |
| 465 | |
| 466 | ### 90-day continuous run cost for hourly plans |
| 467 | |
| 468 | | Plan | 30-day cost | 90-day cost | |
| 469 | |---|---:|---:| |
| 470 | | B3-8 | $36.58 | $109.73 | |
| 471 | | B3-16 | $73.15 | $219.46 | |
| 472 | | B3-32 | $146.38 | $439.13 | |
| 473 | | B3-64 | $292.68 | $878.04 | |
| 474 | | B3-128 | $585.43 | $1756.30 | |
| 475 | | B3-256 | $1170.86 | $3512.59 | |
| 476 | | C3-4 | $32.62 | $97.85 | |
| 477 | | C3-8 | $65.30 | $195.91 | |
| 478 | | C3-16 | $130.54 | $391.61 | |
| 479 | | C3-32 | $261.14 | $783.43 | |
| 480 | | C3-64 | $522.29 | $1566.86 | |
| 481 | | C3-128 | $1044.58 | $3133.73 | |
| 482 | |
| 483 | ### Best use of the free credit |
| 484 | |
| 485 | If your goal is to stay inside the **full 90-day credit window**: |
| 486 | |
| 487 | - **C3-4** fits easily, but is too small for serious public production |
| 488 | - **B3-8** fits easily and is a better balanced early-stage OpenVibe.Live box |
| 489 | - **C3-8** also fits the 90-day window and gives more CPU than B3-8 |
| 490 | - **B3-16** almost makes it, but not quite; you would need extra spend after around **82 days** |
| 491 | |
| 492 | ### Best credit strategy |
| 493 | |
| 494 | A practical strategy would be: |
| 495 | |
| 496 | #### Strategy A — longest useful beta under credit |
| 497 | |
| 498 | - run **B3-8** or **C3-8** during buildout, staging, feature validation, and low traffic |
| 499 | - upgrade to **B3-32** only when audience and VOD usage justify it |
| 500 | |
| 501 | #### Strategy B — realistic public beta |
| 502 | |
| 503 | - start on **B3-16** |
| 504 | - accept that the $200 credit covers only about **82 days** |
| 505 | - resize to **B3-32** when you actually need the larger bandwidth/storage envelope |
| 506 | |
| 507 | #### Strategy C — short burst launch |
| 508 | |
| 509 | - use **B3-32** for launch testing, promo, or a public event |
| 510 | - know that the $200 credit only gives you around **41 days** continuously |
| 511 | |
| 512 | --- |
| 513 | |
| 514 | ## 7. Recommended picks by scenario |
| 515 | |
| 516 | ## Scenario A — dev, staging, private alpha |
| 517 | |
| 518 | ### Pick |
| 519 | |
| 520 | - **B3-8** |
| 521 | |
| 522 | ### Why |
| 523 | |
| 524 | - cheapest balanced plan in the strong family |
| 525 | - enough for app setup, testing, internal streams, chat, docs, and smoke validation |
| 526 | - credit lasts long enough to cover the 90-day window easily |
| 527 | |
| 528 | ### Use if |
| 529 | |
| 530 | - audience is small |
| 531 | - you are validating infrastructure |
| 532 | - you are not storing lots of VODs yet |
| 533 | |
| 534 | --- |
| 535 | |
| 536 | ## Scenario B — public beta, one main stream, realistic growth |
| 537 | |
| 538 | ### Pick |
| 539 | |
| 540 | - **B3-16** if budget is tight |
| 541 | - **B3-32** if you want the plan that actually makes the most sense |
| 542 | |
| 543 | ### Why `B3-32` wins here |
| 544 | |
| 545 | Compared with `B3-16`, it gives you: |
| 546 | |
| 547 | - 2x RAM |
| 548 | - 2x vCPU |
| 549 | - 2x disk |
| 550 | - 2x network |
| 551 | |
| 552 | for exactly 2x price, but the operational breathing room is much better. |
| 553 | |
| 554 | For OpenVibe.Live, that extra room matters. |
| 555 | |
| 556 | --- |
| 557 | |
| 558 | ## Scenario C — target up to 200 concurrent viewers on one box |
| 559 | |
| 560 | ### Pick |
| 561 | |
| 562 | - **B3-32** as the minimum serious answer |
| 563 | - **B3-64** as the safer answer |
| 564 | |
| 565 | ### Why |
| 566 | |
| 567 | For 200 viewers, the question becomes: |
| 568 | |
| 569 | - what is your average delivered bitrate? |
| 570 | - how WebRTC-heavy is the workload? |
| 571 | - how much VOD retention are you keeping locally? |
| 572 | |
| 573 | If the deployment is mixed and audience is real, **B3-32** is the first plan that feels like a deliberate production choice rather than a compromise. |
| 574 | |
| 575 | If you want less stress, especially with WebRTC and recording, use **B3-64**. |
| 576 | |
| 577 | --- |
| 578 | |
| 579 | ## Scenario D — WebRTC-first, higher CPU pressure, future growth |
| 580 | |
| 581 | ### Pick |
| 582 | |
| 583 | - **B3-64** |
| 584 | |
| 585 | ### Why not `C3-32` first? |
| 586 | |
| 587 | Because `B3-64` is only slightly more expensive and gives you: |
| 588 | |
| 589 | - more RAM |
| 590 | - more network |
| 591 | - equivalent vCPU count |
| 592 | - better general OpenVibe.Live balance |
| 593 | |
| 594 | --- |
| 595 | |
| 596 | ## 8. Final recommendation |
| 597 | |
| 598 | If you want the single OVH plan from this list that makes the most sense for OpenVibe.Live, including storage, mixed real-time features, and streaming toward **200 viewers**, choose: |
| 599 | |
| 600 | ## **B3-32** |
| 601 | |
| 602 | That is the best overall compromise of: |
| 603 | |
| 604 | - price |
| 605 | - RAM |
| 606 | - vCPU |
| 607 | - NVMe storage |
| 608 | - outbound bandwidth |
| 609 | - realism for local VOD/clip retention |
| 610 | |
| 611 | If you want the safer no-regrets version for heavier WebRTC usage or more operational headroom, choose: |
| 612 | |
| 613 | ## **B3-64** |
| 614 | |
| 615 | If you want the cheapest plan that is still worth using while you burn the free credit and build things out, choose: |
| 616 | |
| 617 | ## **B3-8** |
| 618 | |
| 619 | --- |
| 620 | |
| 621 | ## 9. Bottom line in one sentence |
| 622 | |
| 623 | - **B3-8** = best cheap build/test box |
| 624 | - **B3-16** = okay starter production box |
| 625 | - **B3-32** = best overall OpenVibe.Live plan |
| 626 | - **B3-64** = best safer 200-viewer / WebRTC-heavy plan |
| 627 | - **B2 / C2** = mostly not worth it here |
| 628 | - **C3** = only worth it if you are unusually CPU-biased and accept weaker overall value for this app |
| 629 | |
| 630 | --- |
| 631 | |
| 632 | ## 10. OVH Ubuntu known gotcha — `node` not found |
| 633 | |
| 634 | OVH Public Cloud instances running Ubuntu (especially 25.04) may not have `/usr/bin/node` after installing the NodeSource package. The `systemd` service will fail with: |
| 635 | |
| 636 | ``` |
| 637 | /usr/bin/env: 'node': No such file or directory |
| 638 | ``` |
| 639 | |
| 640 | After installing Node.js, verify and fix: |
| 641 | |
| 642 | ```bash |
| 643 | which node # should print /usr/bin/node |
| 644 | sudo ln -sf "$(which node)" /usr/bin/node |
| 645 | ``` |
| 646 | |
| 647 | See [SETUP.md](SETUP.md) §8 and §20 for the full fix. |
| 648 |