SafePass24
Access control and student entry/exit tracking
A system for managing card-based access at schools and organizations, helping parents follow their children’s entry and exit.
- Who is it for?
- Organizations, access administrators and parents
- My contribution
- Independent project · Full-stack development
The need to solve
Schools and organizations need to manage access control and devices, while parents need to follow their children’s entry and exit. Access decisions must continue when connectivity drops.
What it enables
Manage card-based access, let parents follow their children’s entry and exit, continue using local permissions without internet and send records to web and mobile applications when connectivity returns.
What I built
I worked on software for card readers and turnstiles, the server side and connections to web and mobile applications. I connected physical access events to records people can follow in the applications.
Application screens
Choose a screen to explore how the app supports student tracking and school management. Screenshots show the Turkish interface.
Explore development details
For readers interested in the technical approach: workflows, technologies and implementation decisions.
How does the process work?
Device commissioning, access decisions and application monitoring are connected processes. If connectivity drops, the controller continues using local permissions.
Main flow
Commission the device
Configure the controller, readers, relays and camera; pair the device with the backend.
Read the card
Process the card UID received through OSDP / RS-485 and protect it with an HMAC hash.
Decide access
Use remote authorization when available. Fall back to the SQLite permission cache if a remote decision cannot be obtained.
Control the passage
Activate the Modbus relay for authorized access and associate the decision with an access event.
Associate the event and image
Prepare an event-linked camera snapshot through ONVIF / ISAPI and RTSP / FFmpeg; encrypt the local image.
Synchronize events to the cloud
A persistent outbox and retries deliver events to the backend after connectivity returns.
Monitor on web and mobile
Administrators follow access records within their permission scope, while parents follow their children’s entry and exit through Next.js / Flutter applications.
Alternative and supporting processes
When remote authorization is unavailable
- Check local permissions
The SQLite cache reduces the access decision’s dependency on connectivity.
- Keep the event durably
Write the offline event to the outbox; synchronize it at step 6 once connectivity returns.
When device configuration changes
- Distribute configuration
Synchronize device configuration over MQTT.
- Apply the new settings
The controller uses the updated configuration for subsequent reader and access events.
The approach
- Translated client needs into edge-controller requirements for readers, RS-485, relays, cameras and Linux runtime; developed controller software matched to the hardware.
- Integrated OSDP/RS-485 readers through Go/CGO and libosdp, and turnstile relays through Modbus; built event-linked camera snapshots using ONVIF/ISAPI and RTSP/FFmpeg.
- Implemented SQLite authorization-cache fallback, a persistent outbox and retry mechanisms for offline access decisions and event synchronization after reconnection.
- Worked on HMAC hashing for card UIDs, AES-GCM encryption for local camera images and device-scoped communication controls.
- Built a modular Go/Fiber backend with multi-tenant data isolation and JWT/OTP flows; developed APIs for Next.js/Flutter clients, device commissioning and MQTT configuration sync.
- Configured GitHub Actions CI for Go tests, race detection and govulncheck; published images to GHCR and signed them with Cosign.
Technologies
- Go
- Next.js
- TypeScript
- Flutter
- PostgreSQL
- Redis
- MQTT
- SQLite
- MinIO
- Docker
- Nginx
- OSDP / Modbus