For School IT Administrators

Approving Pixel Game Lab on your network

Pixel Game Lab is a browser-based game design and pixel art tool used in schools and after-school programs, built by Game Design Academy®. This page has everything you need to review and allow it on student devices. If anything here is missing, please contact us and we will answer the same day.

Short version: allow pixelgamelab.com, portal.gamedesignacademy.com and our storage host (section 1), allow cookies and site storage for both sites, and keep the display at its normal size on small Chromebooks (section 7). No install, no extension, no single sign-on setup.

1. Domains to allow

Pixel Game Lab runs entirely in the browser over standard HTTPS on port 443. No installation, no extension, and no plugin is required. Teachers use two sites: Pixel Game Lab to create with their class, and the Education Portal to manage it. Students use Pixel Game Lab only.

Please allow the storage host together with the two sites. Allowing only pixelgamelab.com gives a page that opens and signs in but shows no artwork and cannot save pictures, which looks like a broken site rather than a filtered one.

Domain	Purpose	Status
pixelgamelab.com	Pixel Game Lab, the creation app students and teachers use (www.pixelgamelab.com redirects here). Includes sign-in.	Required
portal.gamedesignacademy.com	The Education Portal (your school's portal) where teachers and school staff manage classes, students and licenses. Students never use it.	Required for staff
pixelgamelab-assets.ced0cb7ea4c471c6958e4205bba714ee.r2.cloudflarestorage.com	Our storage for every drawing, level picture, background and tutorial video. The browser downloads from it and uploads saved artwork to it (HTTPS GET and PUT). Blocked ⇒ the app opens but every drawing is blank and saving pictures fails.	Required
stun.l.google.com, stun1.l.google.com (UDP 19302)	Only for online co-op, when 2 to 4 classmates play one game together. It helps the devices find each other; game data then goes device to device. Blocked ⇒ co-op does not connect; everything else works.	Optional
challenges.cloudflare.com	Bot check on the public sign-up form only. School students and teachers never sign up there.	Not needed

If your filter prefers a wildcard for storage, *.r2.cloudflarestorage.com is equally acceptable. Storage links are private, signed and expire after a short time, so a cached or shared link stops working on its own.

Cookies and site storage must be allowed for pixelgamelab.com and portal.gamedesignacademy.com. The sign-in session is a first-party cookie; no third-party cookies are used.
SSL inspection is fine, as long as the storage host is allowed for both downloads and uploads.
Filter category. Some filters file anything with “game” in the name under Games. If yours does, please ask your filter vendor to list pixelgamelab.com as Education, or add it to your allow list.
Email. If staff receive email from us (for example a password reset), it comes from noreply@gamedesignacademy.com.

2. Allowing the creation tools without the public games catalog

Some districts allow classroom software but not sites where students can browse and play games. Pixel Game Lab supports that split, and the classroom work is unaffected.

Everything the curriculum uses — the Pixel Art, Level Design and Game Package tools, and playing a game the student has just built — lives outside the public catalog. Only the catalog of already-published games sits under /games.

Path	What it is	Needed for class?
pixelgamelab.com/games	Public catalog of published games — browsing and playing other people’s work.	No
Everything else	The three creation tools, the student’s own library and classes, and testing the game they are building.	Yes

If you block /games, this is what changes: students can still design, build, test and publish a complete game. They cannot browse the public catalog, and they cannot open a game once it has been published — including their own class’s. Teachers who want to show finished work to the class will need the catalog allowed, or can show it from a staff device.

We would rather tell you this than have it discovered mid-lesson. If the catalog is the only thing standing between your district and an approval, block it — the program works without it.

3. How teachers and students sign in

No single sign-on to set up. We do not use Google, Clever or ClassLink sign-in, so there is nothing to configure in your identity system.
Accounts are created by the school or by us, in the Education Portal, one at a time or from a class list. Students never sign up themselves.
Students sign in at pixelgamelab.com with the school code and class code, then tap their own name. A password is asked only if the teacher turns it on for that student.
Students can sign in only during class. The teacher starts a class session, and it ends by itself after 6 hours. Outside a session the codes show nothing, not even the class list.
One device per student. An account already signed in somewhere else cannot be signed in again until it signs out (or has been closed for a few minutes), so one student cannot quietly use another’s account.
Teachers use the same username and password for the Education Portal and for Pixel Game Lab.

4. What we collect from students — and what we do not

Pixel Game Lab is built for children, and its data handling is deliberately minimal. Students in a school program are given accounts by their school; they never sign up themselves and are never asked for personal information by us.

No advertising, ever. There are no ads and no ad networks anywhere in the product.
No third-party analytics or tracking. We removed analytics entirely rather than track children. Nothing about student behaviour is sent to any outside company.
No email address or phone number is collected from students. School accounts are created by the school and used with the school and class codes.
No student work is public by default. A game is only visible outside the class if it is deliberately published, and every publication is reviewed by a human first.
Published school work is credited collectively — for example “GDA Carlstadt students” — so no child is ever named on a public page.

What is stored for a school student:

Their name as the school enters it, their school, class, grade, and device number if the teacher uses one.
A username and password the school sets. The class’s teachers can see the password so they can help a student sign in.
A parent or guardian contact (name, email, phone) only if the school chooses to enter one. It is optional and never shown to students.
The artwork, levels and games they make, and their in-app progress (tutorial videos watched, rewards unlocked).
For security and support: when they last used the app, sign-in records including the IP address (deleted after 90 days), and app error reports. These go to our own systems only.

That is the complete list.

5. Security, hosting and compliance

HTTPS everywhere. All traffic is encrypted; the site is served over TLS on port 443 only.
Data residency. Application and database hosting are in the United States.
Access control. Students see only their own work and their classmates’ work within their own class. Teachers see only the classes and students of their own school.
Communication. Students have no chat of any kind. Friends, messaging and the community art marketplace are turned off for school accounts. Classmates can play a game together in co-op, which carries game moves only, never text.
Moderation. Nothing a student makes is public unless it is published, and every published game is reviewed by a person (the class’s teacher or our team) before anyone outside the class can see it.
Deletion. Account and content deletion is available on request and is carried out immediately — see our data deletion page.
COPPA. The service is designed around COPPA’s data-minimisation requirements. Full detail in our Privacy Policy.

6. Data privacy agreements

Most districts cannot approve any service, however small, without a signed student data privacy agreement. We understand that and we are not asking for an exception.

We work with the Student Data Privacy Consortium (SDPC) National Data Privacy Agreement, the standard instrument used across US districts, rather than asking you to review a contract of our own. Where a district belongs to a state alliance, the National DPA includes Exhibit E, the General Offer of Privacy Terms, which lets other districts in that alliance adopt the same executed terms by countersigning instead of negotiating from scratch.

In New Jersey, that alliance is the New Jersey Student Privacy Alliance (NJSPA), run by NJETA in partnership with The Education Cooperative’s Student Data Privacy Alliance. If your district works through NJSPA and does not yet find us in the SDPC registry, submit a new request assigned to TEC and let us know — we will complete it from our side.

If your district uses its own agreement instead, send it to us and we will complete it. We would also rather answer your privacy questionnaire early than have it hold up a teacher’s request later — get in touch.

7. Device requirements

Chromebooks (Chrome), Macs and iMacs (Safari or Chrome), Windows (Edge or Chrome) and iPads. Any up-to-date browser works; nothing to install.
Screen: the creation tools need a landscape window at least 1000 pixels wide. Every iMac and laptop is fine. On a small 11-inch Chromebook keep the display size at its normal setting (Settings ▸ Device ▸ Displays); enlarging it can make the screen too small for the tools, and the app will say so.
Input: a mouse or trackpad works best for drawing; touch screens work too.
Sound is used in games but is not required; headphones help in a classroom.
Network: light. The app and its artwork are small; tutorial videos stream only when opened.
Phones can play published games but cannot run the creation tools or the Education Portal.

Questions, or need something in a particular format? Email us — we are a small team and answer quickly. You can also read the School Partnerships page for how schools use Pixel Game Lab.