How Publishing Works

The Template Project

Everything starts with the template: a complete, preconfigured Unity 6 project you download and open like any other Unity project. It isn't a plugin you install into an existing project. It's the project, with the hard parts already set up for you.

Built into it, you'll find:

• The Creator Dashboard, an editor window that guides you through setup, holds all the one-click interactivity tools, checks your project for problems, and publishes your work. It's your home base, and it opens automatically when Unity starts. The Creator Dashboard & Setup guide covers it in full.
• Multiplayer, already wired up. When two people open your published URL, they see each other, no networking work required from you.
• A ready-to-play character with configurable AAA movement, camera, and avatar animation. Press Play and walk around your scene from minute one.
• Publishing, built into the dashboard as a button. Everything on this page exists to make that button work.

You build your experience inside this project: import your models, design your space, add interactivity with the dashboard tools. When it's ready, you publish it from the same window.

Your Account and Creator Name

Your Unreality3D account is a simple email and password login, created right inside the dashboard. It exists so the platform knows who you are, which matters for exactly one big reason: your creator name.

During setup, you reserve a creator name. That name is yours permanently, and it becomes your address on the platform. Everything you ever publish lives under it:

unreality3d.com/yourname/

Each experience you publish gets its own product name under that address, so a finished link looks like unreality3d.com/yourname/productname/. Capitals, spaces, hyphens, and underscores are all fine in the name you pick; a URL-safe version is created automatically for your web address.

Because the name is permanent and it anchors every link you'll ever share, it's worth choosing one you're happy to build on. The setup flow checks availability as you go and offers suggestions if your first choice is taken.

The GitHub Connection

This is the part of setup that surprises people, so here's the plain version: when you publish, your finished build doesn't get uploaded into some storage you can't see. It goes into a repository that belongs to you, on your own free GitHub account. A repository is just a project folder that GitHub keeps online, and GitHub Pages, a standard GitHub feature, serves those files to anyone who visits.

This arrangement is deliberate. Your published work sits in an account you control, visible to you, downloadable by you, and it stays there regardless of anything that happens to this platform.

To put files into your repository on your behalf, the dashboard needs your permission, and that permission takes the form of a token: a long code you create on GitHub and paste into the dashboard, one time. Three things worth knowing about it:

• You create it, and you can see exactly what it allows. The guided setup walks you through GitHub's token form. The token authorizes only two things: managing repositories and updating the automation that turns your upload into a live page. Nothing else on your GitHub account is touched.
• It stays on your computer. The token is stored privately on your machine so the dashboard can publish for you. It is not sent to or kept by the platform.
• It expires on purpose. Setup recommends a 90-day expiration because that's good security practice. GitHub emails you before it expires, and making a fresh one takes two minutes. Your published work is never affected by an expired token; you only need a valid one when you publish.

The setup guide walks through the token steps one by one.

What Clicking Publish Actually Produces

When you click publish in the dashboard, your Unity scene is built into a WebGL version: the browser-ready form of your experience that runs on the web without any downloads or installs for your visitors. That build is uploaded to your repository, and a few minutes later your experience is live at your link:

unreality3d.com/yourname/productname/

From there, the platform takes care of the parts that surround your work:

• Your professional URL. Visitors reach your work through your unreality3d.com link, even though the files live in your repository.
• Discovery. Your published experience is listed so other people on the platform can find it.
• Multiplayer. Visitors who open your link at the same time share the space automatically.
• Payment tools. If you've set up monetization, the tools you placed in your scene, like tip jars, work at your live URL.

Sharing your work is now just sharing a link. No downloads, no app stores, no "trust me, it's cooler than the screenshots."

What Updating Means

Publishing isn't a one-time event. When you improve your experience and publish again with the same product name, the new build replaces the old one in the same repository, and your URL never changes. Every link you've ever shared, on your portfolio, in a post, in a message, now points at the newest version.

This is worth internalizing early: you don't have to get it perfect before you publish. Put it out, share the link, improve it, publish again. The link keeps up with you.

Ownership

Your published content lives in your repository, in your GitHub account. You can open it and look at every file, download the whole thing whenever you want, and it remains yours. The platform serves your work at your unreality3d.com address and claims nothing in it.

The same goes for your Unity project itself. The template is standard Unity and C#. There's no proprietary lock-in; your project stays a normal Unity project that you control.

What "public" means for your repository

On a free GitHub account, repositories that serve a site through GitHub Pages are public. That's how the free plan works for everyone using it, so the large majority of Pages sites are public repositories. It's the ordinary condition of the service rather than something unusual happening to your project.

It's worth being precise about what's actually in there. The repository holds your finished web build, not your Unity project. Your scenes, prefabs, source models, layered textures, and scripts all stay on your computer. Scripts don't travel as scripts either: Unity converts them into the compiled form a browser runs, so what ships is built output rather than readable source. The build is also stored in pieces so large files fit within GitHub's limits, and reassembled when your experience is served.

The clearer way to think about exposure is that publishing to the web is the exposure, and the repository adds very little to it. Anything a visitor's browser downloads in order to play your experience has, by definition, arrived on their computer. That's equally true of every browser game on every host, whether the files come from a public repository, a private one, or your own server. Specialist tools can pull runtime versions of assets out of a compiled build, though what comes out is the converted, compressed form rather than your working files, and doing it takes deliberate effort. It isn't common. It is possible, and the sensible conclusion is a simple one: publish work you're glad to have out in the world, and keep anything you couldn't stand a stranger holding a copy of out of a published build. Client work under an agreement and unreleased assets belong in a project you haven't published yet.

If you'd still rather your repository not be browsable, GitHub Pro, their paid personal plan, allows Pages to publish from a private repository. Be clear on what that changes: your repository stops being public, and your live site stays public, because visitors still need to reach it. Sites that are themselves private are an organization and enterprise feature rather than something a personal plan offers.

How much hosting you get

GitHub Pages is free, and generous, with two numbers worth knowing. A published site can be up to 1 GB, which is far more room than a browser experience should ever need. And each site has a 100 GB monthly bandwidth allowance, which is the total amount of data sent to everyone who visits.

That second number is easier to picture as visitors. Every visit sends your experience to somebody, so the smaller your build, the more visits the same allowance covers:

• A 50 MB experience covers roughly 2,000 visits a month.
• A 10 MB experience covers roughly 10,000.
• A 1 MB experience covers roughly 100,000.

Real numbers usually run better than that arithmetic, because browsers hold onto files they've already downloaded and returning visitors don't fetch everything again. It's also a soft limit rather than a switch: going over doesn't shut your work off or generate a bill. Busy sites may be slowed during peak times, and GitHub gets in touch to talk about it.

Both allowances are per project, and you can have as many repositories as you want, so a second experience arrives with a fresh allowance of its own rather than eating into the first one's. If you're expecting real traffic, the most useful thing you can do is keep your build small, which the Optimize tab is built for. A build half the size serves twice the visitors and loads twice as fast, which is worth doing for the second reason even if the first never becomes a concern.

Monetization Is Optional

PayPal setup appears during the guided setup, and it's the one step that's entirely optional. You only need it if you want to use the monetization tools; publishing works without it.

If you do connect PayPal, the split is 95/5: when someone supports your work, 95% goes directly to your PayPal account and 5% helps keep the platform running. Using the platform's payment tools is voluntary, and you can add or change your PayPal email any time in the dashboard. The Monetization guide covers the tools themselves.