Product · Sepul LabsPrivate alpha · Pre-launch

School Network Portal

Network operations workspace for small ISPs

A web workspace for small, third-party network providers that install and maintain internet connections at schools. Engineers record each school site and its devices, allocate subnets and VLANs, set up WireGuard management tunnels, and export RouterOS (.rsc) configuration that they review before it goes on the router.

Built for MikroTik routers running RouterOS. School Network Portal is made by Sepul Labs, which is not affiliated with MikroTik.

Discuss a pilot How we use AI

School status view listing six sample sites with internet, router and switch check results, one site flagged with a failed check. — Working build · synthetic data · English labels for illustration (the interface ships in Bahasa Melayu)

01Capabilities

One workspace, three jobs.

Inventory

Know which school sites you serve and what is installed at each one.

Sites
Devices
Network Discovery

Configuration

Plan addresses and VLANs, then export RouterOS configuration that matches the plan.

Router Configuration (.rsc)
IPAM
VLANs
WireGuard

IP address management table of subnet allocations per site with gateway, DHCP range, status and discovery scan toggle. — IP address plan · synthetic data · English labels for illustration

Assurance

Every change attributable and reviewable.

Audit
AI assistance (planned)

Audit log of administrative actions with timestamp, action, entity, actor and metadata. — Audit log · synthetic data · English labels for illustration

02Who it's for

Built for the small teams that connect schools.

Context: Government school internet programmes in Malaysia rely on small, third-party network providers as well as the big telcos.
The problem: Each school's sites, devices, IP addresses and router configuration are kept by hand: in Winbox, spreadsheets and copied scripts.
Users: The provider's network engineers. The portal is designed as their first-level troubleshooting tool: the first place they look when a school reports a problem.
Who pays: The third-party network provider. Planned pricing is a monthly fee per school site; no prices are set yet.
Support: Support and updates for the length of the provider's contract. The current programme phase runs from 2026 to 2029.

How a pilot starts

You email us about the schools you connect and how you keep their records today.
We talk it through and check whether the portal fits how your team works.
If it fits, we agree a pilot with you: which sites, for how long, and what would count as success.
During the pilot, we adapt the portal to how your engineers actually work.

Discuss a pilot

03AI assistancePlanned · not in the product yet

Where AI saves the engineer time.

We plan to use Claude, through the Anthropic API, in four places. Each one ends with a proposal that an engineer reviews. The first is building the inventory, because most school networks have never had one: the network shows what is installed, people know where it is, and the AI model takes over the tedious work in between. None of this is built yet.

01Build the inventory of each school
Goes in
What the network shows: devices found by the discovery agent (address, MAC, vendor, hostname) and, at the few schools with an access point controller, its list of AP names. Plus what people know: the provider's own spreadsheet, in whatever format it is kept, and photos of device labels taken on a site visit.
AI
Maps the spreadsheet onto sites, blocks and devices. Proposes a block and location for a device only when a name or label points to one, and shows that evidence. Reads the MAC address or serial number from a label photo so the device can be matched. With no evidence, the location stays empty.
Engineer gets
A review list of proposed records, each with its source. The engineer approves, corrects or skips each one before anything is saved.
02Review an existing configuration
Goes in
A .rsc export taken from a router already installed at a school, before it is brought into the portal.
AI
Compares it with the provider's template and the IP plan, and flags differences such as wrong addresses, missing VLANs or management services left open. Address and VLAN mismatches are found by the portal's own parser first.
Engineer gets
A list of findings, each tied to a line in the export, that the engineer works through before importing the site.
03Find the device behind a complaint
Goes in
A complaint as school staff send it to the engineer, usually a WhatsApp message pasted into the portal, in Bahasa Melayu or English (for example "the access point in Block B is not working"), plus that school's inventory: blocks, devices, VLANs and recent check results.
AI
Works out which block and device the complaint most likely refers to, and suggests the first checks to run. If the match is unclear, it says so instead of guessing.
Engineer gets
Links to the likely devices and a short checklist. When the problem is fixed, the portal offers to save the location named in the complaint on the device the engineer chose, so the inventory improves with each complaint.
04Explain and adjust a generated configuration
Goes in
The .rsc file the portal already generates for a site from the provider's template and the site's records, plus the engineer's request when the site needs something non-standard (for example an extra VLAN for a computer lab).
AI
Explains each section of the generated file in plain language. For a non-standard request, it proposes the smallest change and says why. It does not write a configuration from scratch: the portal's own generator stays the source of every file.
Engineer gets
Notes on the file, and any proposed change shown as a diff. The portal checks the changed file against the IP plan and its own validation, and an engineer reviews it before exporting it.

Flow 03, as a design concept

The complaint as staff wrote it, in Bahasa Melayu. The reporter's name is removed before the AI model sees it.
Candidate devices from that school's inventory, each with the record and check result it was matched on.
First checks to run. The engineer decides which device it is and what to do next.

Troubleshooting a site that is down is planned for later, after these four flows.

AISCHOOL-04Concept

1Complaint

“AP di Blok B tak boleh guna sejak pagi.”

Reported by name removed · 08:40

2Likely devices

01
ap-blokb-01 · Block B, level 1 · 192.0.2.41inventory: Block Blast check: failed 08:12
02
ap-blokb-02 · Block B, level 2 · 192.0.2.42inventory: Block Blast check: OK 08:12

3Suggested checks

Re-check ap-blokb-01 now.
Check its switch port on sw-blokb-01 (port 7 in inventory).
If it answers, open its management page.

Open deviceRe-checkNot this device

The AI suggests. The engineer picks the device and runs the checks.

Design concept for flow 03 · sample data · planned · not in the product

04Data

What the portal keeps, and what the AI model would see.

Stored today

Network inventory: sites, devices, VLANs, IP prefixes and addresses, WireGuard peers and WAN links, plus reachability check and discovery results.
Staff accounts for signing in. Access is invite-only.
An audit log of administrative actions and the account that made each one.
An optional name and phone number for each school's ICT contact.

Not stored

Device passwords. Router templates keep placeholders for PPPoE credentials, WireGuard private keys and other secrets.
Student records of any kind.
Personal data about school staff, other than the optional ICT contact listed above.

Planned, with the AI flows

Sent to Claude through Anthropic's API, and only the records a flow needs: for the inventory, that school's discovery results and the uploaded list or photo; for a complaint, that school's inventory and recent checks; for a configuration, that site's records and its generated file.
Names and phone numbers will be removed from complaint text and spreadsheets before they are sent. The ICT contact fields are never sent.
Label photos are used to read a device label and are not kept once the record is confirmed.
The AI model will not connect to routers, and the portal does not push changes: an engineer applies every change.
Proposals, approvals and dismissals will be recorded in the audit log.

Who can see the data, how long it is kept and how it is deleted are agreed with each provider, as the data belongs to them.

Questions about data: founder@sepul.top

05Development statusPrivate alpha

Where things stand.

School Network Portal development status by area
Area	State	Notes
Sites & Devices	Available in alpha	Status comes from on-demand checks. There is no live monitoring. Holds the real inventory of a district office HQ and four schools, imported from their router exports and not in daily use yet.
Network Discovery	Available in alpha	Agent-based scans. Candidates are reviewed before import.
Router configuration	Available in alpha	Generates RouterOS .rsc exports from templates. Nothing is deployed automatically.
IPAM	Available in alpha	New allocations stay proposals until reviewed.
VLANs	Available in alpha	Standard segmentation with per-VLAN access policy.
WireGuard	Available in alpha	Peer and tunnel address allocation.
Audit	Available in alpha	Append-only record of administrative actions.
AI: building the inventory	Planned	First of the four flows. Will use Claude through the Anthropic API. Discovery, which supplies the device list, is already available.
AI: configuration review	Planned	Not in the product yet.
AI: complaint to device	Planned	Not in the product yet. The panel shown above is a design concept for it.
AI: explain and adjust configuration	Planned	Not in the product yet. The portal's own generator stays the source of every configuration.
AI: troubleshooting a site	Planned, later	After the four flows above.
Proposal with a third-party provider	In progress	No users or paying customers yet. The portal is adapted to the provider's needs as the proposal develops.

—Contact

Do you run the network for schools? Pilot School Network Portal with us.

founder@sepul.top

Write to us