Build and publish with managed 360Creator hosting, then export the same tour as a self-contained folder of HTML, JavaScript and images whenever a project belongs on your own infrastructure.
HTML export is included on every paid plan and in the Desktop License.
Managed hosting is the simplest way to publish and update most tours. Portable export gives you another delivery option when a project has different requirements.
The coming-soon Studio plan adds hosted custom domains. Export also lets you place a tour on infrastructure a client already controls, with its own TLS, caching and deployment rules.
Hosted links are convenient for everyday sharing. A standalone folder also gives clients a copy they can archive, move, or hand to another team.
Some tours need to run behind a VPN, on an intranet, or at a venue with no internet. A static export covers those cases without changing the tour.
Nothing exotic ships in the box: static HTML, one JavaScript bundle, one stylesheet, and your panoramas.
index.html, viewer.js, viewer.css, manifest.json and an assets folder. Everything the tour needs is in there.
nginx on your own box, an S3 bucket behind CloudFront, Netlify, GitHub Pages — any static file host works, unchanged.
There is no server-side code to deploy, patch, or monitor. A tour from 2026 will still open in 2036 because it's just a web page.
Serve tours on an intranet, a VPN-only host, or an offline kiosk running a local web server. Nothing calls home.
Tours are served from your hostname, with your TLS, your caching, your analytics, and no third-party requests you didn't add.
manifest.json carries the complete tour — scenes, links, hotspots, settings, branding. Import the folder back into the editor to keep working.
An exported tour is static files. If a host can serve an index.html, it can serve your tour — there is no runtime to install and nothing to keep alive.
my-tour/ index.html viewer.js viewer.css manifest.json assets/
Upload it, point a domain at it, done. No server-side code, no database, no configuration.
You export a tour and get a folder of static files. Upload that folder — keeping its structure — to any static file host and open index.html. There is no server-side code, no database, and no configuration step. The tour runs entirely in the visitor's browser.
No. A self-hosted 360Creator tour is static HTML, JavaScript, CSS and images. Any web server that can serve files — or an object store like S3 with static hosting turned on — is enough. There is nothing to install, scale, or keep patched.
No. The viewer runtime, the fonts, and every panorama ship inside the exported folder, so the tour makes no requests to us. Exported bundles also carry no 360Creator branding or analytics of any kind.
Yes. The exported manifest.json holds the full tour data — scenes, links, settings and branding — alongside the assets folder. Import the two back into the editor and you can continue exactly where you left off, then re-export.
No, and this catches everyone out. Browsers block WebGL from loading textures on pages opened via file://, so the panoramas won't appear. Run any local web server from inside the folder instead — for example `python3 -m http.server 8000` or `npx serve .` — and open the address it prints.
No. Once a tour is exported it belongs to you. It's a folder of files on a host you control, and nothing in it expires, checks a license, or depends on your account staying open.