Communities
Classrooms, study groups, and course communities.
A channel per subject, roles for staff and students, and moderation tools that keep things on topic. Students join from any browser with one link, and nobody has to file an IT ticket to make it happen.
Why classes end up here.
The tools a course actually needs, without the tools it does not.
A channel per subject
Announcements, questions, and assignments each get their own space. Nothing important drowns in chatter, and students always know where to look for the thing they need.
Staff and student roles
Teachers and TAs get moderation powers, students get a voice, and permissions keep the two clearly separate. Nobody deletes a message they were not supposed to touch.
Safe by default
Filters and reports run from day one, and the audit log keeps a record staff can stand behind. When a parent, a dean, or a colleague asks what happened, you have the answer.
Voice rooms for office hours
Open a voice channel, name it after your office hours, and students drop in when they have a question. No meeting links to generate, no calendar invites to lose.
Polls, threads, and pins
Run a quick poll to check understanding, push a long back-and-forth into a thread, and pin the syllabus where nobody can miss it. Students bookmark the explanations they want to find again.
Slow mode for deadline week
The night before an exam, the help channel can move faster than anyone can read. Slow mode paces it so every question gets seen, and every answer stays visible long enough to help.
Nothing to install, nothing to license.
Students join from any browser with one link.
No IT ticket, no seat licenses, no app approval process. Share an invite link and the whole class is in, on laptops and phones alike. Voice rooms handle office hours, and pins hold the syllabus.
That single link is the entire onboarding. Put it in the syllabus, on the first slide of the first lecture, or in whatever learning management system your institution already runs. A student opens it, creates a free account in the browser, and lands in your server. There is no download step where half the class falls off, and no version mismatch where the app works on one student's phone but not another's.
Browser-first also means the oldest machine in the library lab works. If it runs a modern browser, it runs Vronify.chat. Nothing to update, nothing that breaks when a managed device blocks installers, nothing for a school firewall administrator to whitelist beyond one website. A mobile app for iOS and Android and a desktop app for Windows, macOS, and Linux are coming soon, but no one has to wait for them: the browser version is the full product, available now.
And the price fits an education budget, because there is not one. Core features are free forever, with optional extras for power users later and no surprise paywalls. You will never hit a wall in week eight where the class outgrows a free tier. There are also no ads and no trackers, which matters when the room you are running is full of students: nobody is mining your class discussion to sell attention. Read more about that on our privacy page.
Set up a course server in an afternoon.
Five steps from an empty server to a running class. Most of it is deciding names.
Create the server
Name it after the course code or the group, add an icon if you like, and you are done. Creating a server takes under a minute, and everything after it can be changed later without starting over.
Lay out channels in categories
A simple pattern that works: an announcements channel, a general channel, a help channel, and one channel per topic or per week. Group them into categories so the sidebar reads like a table of contents instead of a pile. You can add channels mid-semester as the course moves.
Add staff and student roles
Create a Staff role and a TA role with moderation permissions, and let everyone else default to student. Then use roles and permissions to make announcements post-only for staff, so the one channel everyone must read never fills with replies.
Turn on the safety rails
Enable automated filters, set slow mode on channels you expect to get busy, and skim the moderation tools so you know what is available before you need it. Every staff action lands in the audit log, so there is always a record of who did what.
Share one invite link
Drop the link wherever students already look. As they arrive, ask them to set a per-server nickname that matches the class roster: their nickname in your server does not change who they are anywhere else, so students keep their identity and you keep a readable member list.
Built to keep up with a full lecture hall.
A live Q&A during a lecture is a stress test. We built for it.
Clear powers for staff. Clear limits for us.
A classroom needs authority that is visible and accountable, on both sides of the platform.
What staff can do
- Restrict who can post in each channel with roles and permissions
- Pace busy channels with slow mode before they overwhelm anyone
- Catch problems early with automated filters and member reports
- Remove off-topic or harmful messages, with the action recorded in the audit log
- Hand moderation to TAs without handing them the whole server
What we never do
- Read direct messages: they are private, so we don't
- Show ads or run trackers on students, ever
- Sell anyone's data to brokers or anyone else
- Hold data hostage: anyone can export their data at any time
- Take away an account: a ban only stops participation, never ownership
Three shapes of an education community.
The same building blocks arrange differently depending on what you are running.
A single course
One server per course is the simplest shape and usually the right one. Announcements go in a post-only channel so nothing important gets buried. Each week or topic gets its own channel, which does something a group chat never can: the discussion from week three is still sitting in the week-three channel when revision season arrives. Students scroll back, reread the answers, and follow the threads where the hard questions got worked out. Pinned messages hold the syllabus, the grading policy, and the office-hours schedule, and the whole server quietly becomes the course's searchable record.
A department or school hub
When one server needs to hold a whole department, categories carry the structure: a category per program or per course, with roles gating who sees what. A single server supports 50k+ members, so the constraint is organization, not capacity. Custom emoji and server tags give the place an identity beyond the institutional logo, and server analytics show which channels actually get used, so you prune what nobody reads instead of guessing. If the hub should be findable, list it on the Explore page; if not, it stays invite-only and invisible.
A study group or cohort
Small groups need less structure and more speed. A couple of channels, a voice room for co-working sessions where everyone works quietly together, and a poll whenever the group needs to pick a meeting time. Bookmarks earn their keep here: when someone finally explains the proof in a way that clicks, you save it, and it is one click away during the exam-week panic. Threads keep a deep dive on one problem from derailing the channel for everyone else.
Running a paid course or a public workshop instead? The shape looks more like a creator community than a classroom, and our creators page covers that pattern. Either way, the Owner Handbook is the reference for everything a server owner can configure.
Privacy that holds up in a classroom.
Students deserve straight answers about who can see what. Here they are.
Direct messages are private. When two students DM each other, only the two of them see it, not us and not their teacher. As a matter of policy, we don't read private conversations, and that is how private DMs work.
Community channels are visible to their community and its moderators, and we say so plainly. That is a deliberate trade-off: it is what lets moderators keep public spaces safe, run filters, and act on reports. In a classroom it means staff can see and moderate what happens in class channels, which is exactly what a classroom needs, and students should know it works that way. The line is simple to teach on day one: channels are the classroom, DMs are the hallway conversation.
Students own their accounts, not the institution and not us. When the semester ends, every student keeps their account and every message they ever sent. They can export their data at any time, and if they want a clean break, they can delete their account at any time, which anonymizes it. Even a ban only stops participation in that server: the banned student keeps their account, their message history, and the DMs they received, unless the sender removed them.
And the business model never works against the students. We never sell data, never show ads, never read private conversations, and never hold data hostage. A class discussion is not an advertising audience. The full details are in the privacy policy, and the expectations we hold every community to are in the community guidelines.
What is coming next
The built-in bot engine is coming soon, and classrooms are an obvious fit: welcome cards that greet each new student and point them at the rules, custom commands that answer "when are office hours" instantly and identically every time, and tickets that let a student raise something with staff privately instead of in front of the class. None of it is live yet; watch the changelog for the release. Mobile and desktop apps are on the way too, and until then the browser version on a phone covers students between lectures.
Questions from teachers and organizers.
How do students join?
With one link. You share the invite, a student opens it in any browser, creates a free account, and lands in your server. There is nothing to install and nothing to configure on their side. It works the same on a school laptop, a library computer, and a phone.
Is it really free for a whole class?
Yes. Core features are free forever: channels, roles, voice, moderation, the audit log, all of it. Optional extras for power users may come later, but there are no surprise paywalls and no per-seat pricing, so a class of three hundred costs the same as a study group of five. Nothing is subsidized by ads or data sales, because we run neither.
Can teachers read students' direct messages?
No, and we don't read them either. DMs are private, so they are readable only by the people in the conversation. Class channels are different: they are visible to their community and its moderators, precisely so staff can moderate them. Tell students this on day one so everyone knows where the public space ends.
What happens when the course ends?
Whatever you want. The server keeps working, so many courses leave it up as a searchable archive and alumni space. Students keep their accounts either way, can export their data at any time, and can delete their account at any time, which anonymizes it, if they would rather make a clean break. Nobody's history is held hostage to anyone else's decision.
How do I keep channels on topic during a busy week?
Structure first, enforcement second. Post-only announcement channels keep the critical channel clean, per-topic channels give tangents somewhere legitimate to go, and threads absorb long exchanges. When volume spikes anyway, slow mode paces the room and automated filters catch the worst before a human has to. The moderation guide walks through the whole toolkit in order.
Can one server hold an entire department?
Yes. A single server supports 50k+ members, which covers most departments with room to spare. Use categories to group channels by course or program, roles to control who sees which category, and server analytics to see what is actually being used. The practical limit is how well you organize it, not how many people fit.
What if we need to remove someone?
Staff with the right role can remove or ban a member, and the action is recorded in the audit log so there is an answer when someone asks what happened and why. A ban stops participation in your server and nothing more: the person keeps their account and their own message history. Removal from a community never becomes erasure of a person.
Will there be a mobile app?
Yes: a mobile app for iOS and Android and a desktop app for Windows, macOS, and Linux are coming soon. In the meantime the browser version works on phones today, so students can follow announcements and ask questions between lectures without waiting for anything. Release news lands in the changelog.
Your community. Your rules. Your data.
Create a server, invite your people, and see what chat feels like when your account actually belongs to you.
Free to start. Live in under a minute. No install required.