Hosting Virtual Tours Explained: Servers, Storage & CDN

Hosting virtual tours means keeping the viewer, scene data, panoramas, and supporting media available online so a visitor can explore them in a browser. The visible experience may feel like one continuous space, but behind it are requests for many separate files and, sometimes, responses from an application.

This explanation separates the jobs of servers, storage, bandwidth, and a content delivery network. It also explains how SaaS and self-hosted delivery divide responsibility. For installation instructions rather than infrastructure concepts, use our practical guide to hosting your own virtual tours.

What Happens When Someone Opens a Virtual Tour?

The tour URL leads the browser to a web service. The browser loads the viewer and project information, then requests the images and media needed for the current scene. Depending on the viewer, it may fetch a whole panorama or smaller image tiles at different resolutions as the visitor looks around and zooms.

The viewer starts: HTML, scripts, and presentation assets establish the interactive experience.
The project loads: Scene connections, hotspot positions, and settings tell the viewer what to display.
Media arrives: Panorama files or tiles, floor plans, audio, and video are delivered when requested.
The browser renders the scene: The visitor's device decodes images and draws the immersive view.

These stages explain why hosting speed and device performance are different things. A fast server cannot guarantee smooth rendering on an overloaded phone, and a powerful phone cannot compensate for a slow connection or unnecessarily large downloads.

Servers: Running the Application and Answering Requests

A server receives requests and sends responses. For a static exported tour, it can simply deliver existing web files. A browser-based authoring platform may also need an application runtime and database to manage projects, authenticate editors, save changes, or process uploads.

Publishing workload and viewing workload are different. Generating image tiles or resizing large panoramas can consume CPU and memory during preparation. Serving already generated images is largely a delivery task. Adding CPU may help processing without solving a visitor's download bottleneck.

The origin is the authoritative source from which files or responses are retrieved. It might be a web server, an application service, or an object storage service. One physical machine does not have to perform every role, and renting cloud infrastructure can still be part of a self-hosted deployment.

Storage: How Much Content You Keep

Storage is the capacity occupied by files and data at rest. Count more than the source panoramas: generated tiles, preview images, hotspot media, project records, and retained versions also take space. Backups and editing masters may live separately, but they still need their own capacity budget.

Local server storage: Files live on storage attached to the application server. Available space and recovery depend on that hosting environment.
Object storage: Files are stored as objects in a separate service. It can separate media growth from application resources, provided the software supports the arrangement.
Backup storage: Recoverable copies protect against deletion or failure. A second live copy or a CDN cache is not automatically a usable backup.

As an illustrative calculation, 40 published projects averaging 250 MB each occupy about 10 GB using decimal units. That excludes backups, source archives, the application, and additional versions. Measure a complete published project instead of multiplying only the original photo sizes. Our virtual tour file formats guide explains why working masters and delivery assets serve different purposes.

Bandwidth and Transfer: How Much Content Visitors Receive

Strictly, bandwidth is a connection's capacity to move data over time, commonly expressed in megabits per second. Hosting plans often use the same word for a monthly transfer allowance, measured in GB or TB. Capacity affects how much can move at once; transfer measures how much actually moves over a period.

A stored tour does not consume the same amount of transfer on every visit. Visitors may open one scene or explore everything; mobile viewers may request lower resolutions; cached assets may be reused. Autoplay video and preloading can change the total substantially.

Illustrative monthly transfer = visits × average delivered data per visit. If 2,000 visits each receive 30 MB, visitor delivery is about 60 GB in decimal units. The 30 MB is an assumed measurement, not a virtual tour benchmark. It is unrelated to the earlier example of total stored project size.

Also distinguish monthly totals from concurrent demand. A campaign that brings many visitors at once can strain delivery even when monthly transfer remains modest. Check how a plan treats transfer limits, throughput, request counts, and excess usage rather than interpreting “unlimited” as unlimited resources.

CDN: Delivering Cached Media Closer to Visitors

A content delivery network distributes cached copies of eligible assets across edge locations. A request can be answered from an edge cache instead of repeatedly fetching the same image from the origin. This can reduce delivery latency and origin traffic, especially for geographically dispersed audiences.

A cache miss still needs an upstream fetch, so a CDN does not remove the need for a working origin. It also does not make a heavy panorama smaller by itself. Image optimization, appropriate resolutions, and sensible loading behavior remain separate parts of performance. See Cloudflare's explanation of CDN delivery for the underlying model.

Cache Rules Must Match the Content

Public panorama tiles can often be cached for reuse. Editor sessions, personalized responses, and restricted tours require rules that respect access controls. A private link is not sufficient if the underlying media remains publicly retrievable. The MDN Cache-Control reference explains how browser and shared caches are directed.

Updates also need a freshness strategy. If a panorama is replaced while its address stays the same, a cached older copy may remain visible until it expires or is invalidated. Versioned asset URLs can separate revisions. CDN configuration should support the application's publishing behavior rather than apply one rule to every response.

Origin Traffic and Visitor Traffic Are Separate

When an edge cache serves a file, the visitor still receives its bytes even if the origin avoids sending them again. Read origin hosting, storage, and CDN billing separately: caching can reduce one transfer line while another service still charges for delivery or requests. Savings depend on the provider's terms and the actual cache behavior.

SaaS and Self-Hosted: Same Building Blocks, Different Operators

Both approaches need compute, storage, and network delivery. The difference is who selects, operates, and pays for the components, and how those costs and controls are presented to the tour creator.

SaaS hosting: The platform operator manages the infrastructure and application. Your subscription or usage plan determines the available capacity, features, support, and publishing conditions.
Self-hosted delivery: You choose a compatible hosting environment and arrange operation yourself or through a managed provider. Infrastructure bills remain separate from the software license.
Managed hosting: A hosting partner can handle specified server tasks without turning the tour software into SaaS. The service agreement defines whether application updates, backups, and recovery are included.

Neither label guarantees speed, portability, or lower total cost. A SaaS service can use a CDN, and a self-hosted platform can run on rented cloud servers. Compare export access, domain control, capacity rules, and assigned responsibilities. Our self-hosted versus cloud comparison addresses the broader business decision.

Read Hosting Specifications by the Problem They Solve

Uploads fail or processing stalls: Investigate upload limits, runtime settings, available memory, CPU, and free storage.
The first scene loads slowly: Examine response time, initial asset size, network distance, and the visitor's connection.
Navigation triggers long waits: Examine scene payloads, tile requests, preloading, and cache behavior.
A busy launch causes errors: Examine concurrent requests, application capacity, origin load, and delivery limits.
Old images remain after an update: Examine browser and CDN caches, asset versions, and invalidation.

Start with a representative tour and observe the browser's network requests alongside hosting usage reports. Separate bytes delivered, response delays, and rendering problems. That distinction makes a hosting specification useful: it connects each resource to an observable part of the visitor experience.

Frequently Asked Questions

Is virtual tour hosting the same as storing 360 photos?

No. Storage keeps the files, while hosting also makes the viewer, project information, and required services available to visitors. A folder of panoramas alone does not provide connected scenes or interactive navigation.

Does every visit download the entire tour?

No. The amount depends on the viewer's loading strategy, the scenes explored, requested resolutions, media playback, and caching. Use measured delivery per visit rather than the total project size to estimate traffic.

Does every virtual tour need a CDN?

No. A small tour serving a nearby audience may perform adequately from its origin. A CDN becomes useful when network distance, repeated asset requests, or traffic distribution justify it; confirm the benefit with actual loading tests.

Does self-hosted mean the server must be in my office?

No. It describes control of the deployment. Rented hosting, managed servers, and cloud accounts can support self-hosted software when they meet its technical requirements.

Will embedding a tour move its hosting to my website?

No. An embedded viewer normally continues to load from its original service, and its media remains delivered by the configured hosts. An embed changes where the tour appears, not automatically where its application and assets live.

Understand the Delivery Chain Before Comparing Plans

A reliable approach to hosting virtual tours starts with separating four questions: what runs the application, where files are kept, how much data visitors receive, and where reusable copies are delivered. SaaS bundles those decisions into a service; self-hosting lets you arrange them with your own providers. Match resources to actual workloads rather than assuming one headline storage figure describes the whole experience.

Simple Virtual Tour offers a self-hosted way to create, manage, and publish interactive tours. Explore the live demo to see the visitor experience, or review the available packages when planning your own deployment.