Run the filter inside your own network, on hardware you control. Student browsing records never leave the district, policy is enforced at your edge, and the categorization data behind it — more than 120 million classified domains — refreshes daily from our side without your traffic ever passing through ours.
Cloud filtering is the fast default, and for many schools it is the right one. On-site web filtering for schools exists for the districts where one of four requirements outweighs convenience.
In an on-premise deployment, the component that decides whether a page loads sits inside your building — typically a virtual machine or appliance at the network edge. Requests from classrooms hit it directly, it consults a locally stored copy of our category database, and it answers in the time it takes to traverse your own LAN.
Nothing about a student's browsing has to be sent to an outside service to make that decision. The lookup happens against local data, the block page is served locally, and the log entry is written to storage the district owns. Your internet link is used for learning traffic, not for round-trips to a vendor.
What does cross the internet is small and one-directional: a signed update feed that delivers fresh category data every day, so a domain registered this week is already classified when a student tries it next week.
Board policy, state guidance or community expectation says student browsing records stay on district-owned systems. On-prem makes that a fact of architecture, not a clause in a vendor contract.
Your team wants to change a policy, grant an exception or pull a log at 7:45 on a Monday morning without opening a ticket with anyone. The console is yours; the change is immediate.
Filtering decisions do not depend on the health of an internet path to a vendor's region. If your LAN is up, the filter is up, at LAN latency — a real consideration for rural links.
The weakness of traditional appliances was never the hardware; it was the data going quiet. A box configured in August with a static list is meaningfully blind by October.
Both deployments run on the same categorized dataset, so blocking accuracy is identical. The trade-offs are operational — and they are real in both directions.
| Decision factor | On-premise | Cloud |
|---|---|---|
| Browsing data stays in-district | Always, by design | Processed by the service |
| Filtering survives WAN issues | Runs on the LAN | Depends on the internet path |
| Full administrative control | Your hardware, your rules | Within the vendor console |
| Rollout speed | Days: provision and integrate | Same afternoon |
| Covers take-home devices | Only via hybrid setup | Follows the device anywhere |
| Hardware to maintain | One VM or appliance | None |
Your governing board treats browsing logs as records that must never sit on third-party infrastructure. The self-hosted model is the only one that answers that requirement directly — and a hybrid can close the take-home gap.
Your 1:1 program sends Chromebooks home every night and your team is small. Start with cloud-based web filtering for schools — cloud wins on speed and reach.
A common fear about appliances is that they run on stale lists. Here, the on-prem deployment consumes exactly the classification stream the cloud service does.
Self-hosting adds a provisioning phase that cloud skips, but for a team that runs its own infrastructure none of these steps will be unfamiliar.
Choose a VM or appliance sized to your concurrent-user count and place it where traffic already converges — usually beside the firewall at the district edge, or per-building for large campuses.
The initial category database is installed locally and the daily update feed is verified, so the box is current before it filters its first request.
Set category rules per elementary, middle and high school, per building and per user group, then layer your own allow and block exceptions on top.
Route one building or VLAN through the filter first, watch the logs with instructional staff for a week, and expand once everyday classroom resources are confirmed to pass cleanly.
Schedule category-level reports from the local log store so the evidence your E-Rate certification depends on accumulates automatically, on your own storage.
Fear of the unknown keeps some districts off on-prem. Here is the honest workload once the system is in production.
The appliance surfaces health, throughput and update status like any other monitored host. Fold it into the dashboards and alerting you already run; it does not need babysitting.
Category data refreshes itself daily. Software updates are applied on your maintenance windows, on your schedule — nothing changes underneath you unannounced.
Because categories cover millions of sites at once, day-to-day work is a handful of allow/block exceptions per term, usually requested by teachers and resolved in minutes.
More students means resizing a VM or adding a node at a new building — capacity planning your team already does for every other core service.
Keep logs exactly as long as board policy dictates and not a day longer. Deletion is a local operation you can verify, not a request you submit.
When a principal or parent asks why a site was blocked, the named category and the log line are on your screen in seconds, with no support queue between question and answer.
Districts routinely feed the AI-tools list straight into an existing resolver or firewall as a first step, then broaden to full category filtering on the appliance.
One advantage of owning your enforcement points is that curated data can plug into them directly. Our bundled blocklist tracks more than 16,000 AI-tool domains — essay writers, homework solvers, image generators, deepfake and voice-cloning tools, companion chatbots — organized into categories and refreshed daily from a screen of roughly 300,000 newly registered domains per day.
Because it ships as DNS RPZ, firewall EDL, PAC and hosts formats, CSV, or an API, it can enforce at your resolver and firewall as well as on the filtering appliance itself. That gives a self-hosted district defense in depth against the fastest-moving content problem in K-12 without adding a single external dependency.
The honest weakness of a purely on-site model is the school bus. Once a managed Chromebook leaves the building, an edge appliance cannot see it. A hybrid deployment resolves this without giving up local custody for campus traffic.
An on-site filter is a direct, inspectable implementation of the technology protection measure CIPA requires — you can walk an auditor to the rack.
The Children's Internet Protection Act requires schools and libraries taking E-Rate discounts to enforce a technology protection measure blocking obscene material, child sexual abuse material and content harmful to minors, alongside an internet safety policy, monitoring of minors' online activity, and education on appropriate online behavior.
Category-level reports demonstrating that the required categories are blocked district-wide come from your own log store, on your own retention schedule, without asking a third party to export anything. Districts standardizing across many buildings get one policy language and one evidence trail; our page on web filtering for school districts covers that consolidation.
CIPA does not require blocking social media outright, so an on-prem deployment should reflect deliberate local policy rather than reflexive maximum blocking. And no filter substitutes for the safety-policy and instruction requirements — our guide to what CIPA requires walks through the full obligation.
Where the filtering engine physically sits shapes both performance and administration, and the right answer depends on how your network is already laid out. A single-building school usually runs one modest VM beside its firewall and is done; every request is filtered a few racks away from the classroom that made it.
A district with a hub-and-spoke WAN, where building traffic already flows through a central point, filters at that hub. One engine, one policy console, one log store — and each campus inherits its grade-band policy automatically based on which network it sits on.
Large or geographically scattered districts place a node per building or per region, all pulling the same daily dataset and the same central policy. Students get LAN-speed decisions everywhere, and a WAN outage at one campus never takes filtering down at another.
On-prem costs concentrate differently than cloud costs — but for districts with existing virtual infrastructure, the incremental hardware cost is frequently close to zero.
Instead of a pure per-student subscription, you are combining a license for the filtering software and its daily data feed with infrastructure you largely already own — hypervisor capacity, rack space, backup. For districts with an established virtualization footprint, the incremental hardware cost is frequently close to zero.
Count the hours your team will spend on provisioning and the phased cutover, then weigh them against what local custody saves elsewhere: no vendor data-processing review for browsing logs, no export requests before an audit, no dependency clauses to negotiate. For many technology directors, the second column is why the project gets board approval.
Because filtering underpins the E-Rate certification, schedule the deployment so the system is enforcing policy and accumulating category-level evidence before the school year — and the certification window — arrives. A spring pilot with a summer cutover is the pattern that avoids filtering a live student body during week one. Licensing details for both deployment models are on our pricing page.
Talk through sizing, network placement and a phased cutover with an engineer, and see the daily-updated dataset running on infrastructure you control.