Publishing and access

Saving a place to Roblox and making it playable by a particular audience are separate decisions. Prepare a known build, decide who should access it, and verify that those accounts can actually join before arranging a play session. A family-friendly design does not by itself establish platform eligibility for younger players.

Prerequisites: A saved backup, completed multiplayer checks, reviewed assets, and the owner's own Roblox account. This is a guide for your decisions; the manual has not created an account, changed security settings, published an experience, paid a fee, or invited anyone.

Outcome: A release checklist and an explicit audience choice. It is fine to stop at a local project or a private cloud copy.

Check the current rules first

Checked 2026-10-03: Roblox's detailed publishing guidance says Private is for the owner and users with Edit permission. Playtest-only users need Limited > Playtesters. Public/Limited publication has account-standing, account-age, age-check, and maturity/compliance requirements. Reaching all ages, including Kids and Select, adds verification, 2FA, a subscription-history or fee route, and an evaluation process. Do not assume publishing to every audience is always free.

The page's introductory paragraph still mentions private playtest access, contradicting its detailed audience and requirements sections. This manual follows the detailed sections. Recheck your account's Creator Dashboard and current guidance before promising access. Publishing requirements and audience options

Complete any identity checks, security changes, payment, or legal acceptance yourself through Roblox's official flow after reviewing what it asks. Never falsify ages or borrow another person's identity to get around eligibility.

Prepare a release candidate

Give the build a short internal name, such as “Co-op Garden test 1,” and write its intended audience. Preserve a local place backup before publication. Keep the persistence lab separate; it must never become the production place by accident.

Check these items before changing access:

• The start location is safe and the objective is understandable without coaching
• Two players can complete a round, respawn, and leave without breaking it
• Touch and controller tests reflect the devices you plan to support
• No imported script remains unexplained
• No secret, personal contact information, or private family detail is in scripts, signs, thumbnails, descriptions, or logs intended for sharing
• The build makes no purchase or persistence promises that you have not implemented and tested
• Known limitations are written down and acceptable for this test

For a small first release, exclude monetization entirely. Focus on whether someone can join, understand the goal, and enjoy one complete loop. That recommendation is a scope choice for this course, not a platform requirement.

Save to the correct destination

In Studio, use File > Publish to Roblox for the current experience. On first publication, carefully review the name, description, creator, and supported devices before creating the experience. “Publish to Roblox As” can target a different destination; never click through an overwrite without checking it. Official publishing workflow

After saving, open the experience in the Creator Dashboard and verify its identity. A similar title is not enough: confirm the correct place/experience rather than accidentally modifying a test copy. Roblox retains place version history, which supports inspecting and reverting prior saved versions. Keep a local backup too, and remember that restoring a place version is not a rollback of persistent player data. Configure games and places

Choose the least access needed

Write down who is meant to play and who is meant to edit. Those are different capabilities. Do not grant Edit access merely to work around a playtest eligibility problem. Do not change the audience to Public simply because an invitation failed.

For a limited test, use the audience and collaborator controls currently available to your account, verify the exact usernames, and check that the selected users have the intended playtest permissions. Keep the approved list small and review it after the test. Public availability should be a conscious release decision, not a troubleshooting experiment.

A conditional family-testing route is documented in the Kids and Select FAQ: playtesters who are Trusted Friends of an age-checked owner may join a Limited > Playtesters experience regardless of age when its maturity questionnaire is complete. Ordinary friendship is not proof of Trusted Friend status; verify eligibility and actual access first.

Before inviting a child, the responsible adult should check their account's applicable access settings and the experience's reach requirements. If access is unavailable, use Studio together on the Mac: one person builds while another tests or sketches the next obstacle. You can keep learning without bypassing a platform boundary.

Answer the content questionnaire honestly

Review the whole experience, including imported assets and uncommon paths. Answer for content a player can actually encounter, not just the cheerful start screen. The questionnaire supplies maturity information and regional compliance results; publishing changed content can require revised answers. A suitable maturity label alone does not satisfy all younger-audience publishing requirements. Content maturity and compliance and Kids and Select

For this course, consider visual hazards, scary sounds, user creation features, and any social elements you added. Do not automatically choose the least restrictive answer because the intended players are family. If a question is unclear, read its current explanation and alter the design if necessary.

Verify from the player's side

Open the published experience using the intended account and Roblox client. Confirm the correct version, start location, device controls, and one complete round. Verify a tester can actually join before sending a time-specific invitation. Sharing a link is not evidence that access works.

If joining fails, record the exact message and check the destination, audience, permission, account eligibility, maturity information, and asset errors in that order. Avoid repeated unrelated settings changes; they make the cause harder to identify. Keep screenshots of account settings private.

For updates, repeat the focused regression cases. Existing running servers may not all be using the same build; plan any server restart deliberately and warn active testers before disrupting their session. See the configuration and version-history guidance.

Exercise and completion check

Write a five-line release note: what the game is, who may test, how to start, what is new, and one known limitation. Have someone who did not build it follow those instructions. Revise only the confusing parts, then repeat the join test.

You are done when the destination, version, audience, permissions, and actual join result are known. “Ready to publish” and “published and verified” are different statuses; record the truthful one.

Verification: Links and detailed publishing rules checked 2026-10-03. Requirements may change and the official page contains the inconsistency described above. No account-specific eligibility or live join test was verified for this manual.

Previous: 17 Assets and Toolbox · Next: 19 Build with family

Related: 14 Testing multiplayer · 15 Saving progress · 20 Get help and next steps