Open-source project
portabilis/i-educar avatar
portabilis/i-educar

i-Educar is Brazil's public school management system

Lançando o maior software livre de educação do Brasil!

720 stars549 forksPHPGPL-2.0

At a glance

What is it?
i-Educar is a fully online school management system built for Brazilian municipalities, where the person typing at the front desk replaces the paper records. It began in the Itajai city hall in 2008 and became the largest free educational software in Brazil, and its most interesting feature for developers is a module system that lets separate packages extend the core.
Who is it for?
Adopt i-Educar if you run a Brazilian public school network and need enrolment, attendance and reporting in one place, because it has been in production across the country since 2008 and carries the domain rules Brazilian municipalities actually work under.
Can I use it commercially?
Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 8 days ago.
What is it written in?
Mainly PHP, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The problem it solves is paper, not features

i-Educar is a free school management system that is entirely online, and it allows school secretaries, teachers, coordinators and managers to use a tool that produces information and statistics in real time, with a centralised and easily accessible database, reducing the need for paper, the duplication of documents, citizen service time, and rationalising the public servant's work.

That sentence is the most useful description of the system, because it tells you the design centre. The listed beneficiaries are four different roles, the secretary who serves the public at a counter, the teacher, the coordinator and the manager, and the value is in the record existing once rather than four times on paper.

The origin story is given as one line. It was originally developed by the Itajai city hall in Santa Catarina and made available on the federal government's Public Software Portal in 2008, with the aim of serving the needs of the Education Secretariats and Public Schools of all of Brazil. The project is maintained by Portábilis and the repository topic tags include software-publico, which is the Brazilian government category for software developed for public administration.

The scale claim in the README is that this is the largest free educational software in Brazil, and the project describes itself as the i-Educar Community, with the stated belief that the project can transform the country through education.

The project is PHP and GPL-2.0 licensed, with the default branch 2.12, the last push on 2026-10-14 and releases 2.11.0 from 2026-06-02, 2.10.0 from 2025-07-02 and 2.9.0 from 2025-05-06. The homepage is ieducar.org.

The module system is the extension point

i-Educar has a set of packages, modules, that extend it and make it a more capable piece of software, and to install one you follow the installation instructions in the project repository.

The listed modules are all separate repositories from the same organisation. Pré-Matrícula Digital, for digital pre-enrolment. A reports module, a library module, a transport module, and an Educacenso module, the last being the interface to Brazil's national education census.

The reason this matters is that a school management system in Brazil has to satisfy national reporting requirements, and the census is the sharpest example. A module that handles Educacenso isolates one of the most demanding and most regulated integrations from the core, which means the core does not have to change when the census schema changes.

The same logic applies to pre-enrolment. That is a distinct workflow with its own rules, and a separate package means a municipality can install it without pulling it into every other deployment.

So the module system is not a plugin mechanism for end users, it is how the community partitions a system that has to serve thousands of municipalities with different local requirements. The trade-off is the usual one: separate packages mean separate version lines, and a core upgrade can require a coordinated module upgrade.

The local stack is PHP 8.5, PostgreSQL 18 and Redis 8

The compose file tells you the runtime, and the versions are pinned tightly.

The PHP service builds from docker/php with PHP_VERSION 8.5 and COMPOSER_VERSION 2.10, producing an image tagged php:8.5-ieducar, with the project mounted at /var/www/ieducar and HOST_UID and HOST_GID passed through so the container runs as the host user. There are three PHP-derived services: ieducar-php running a tail command for interactive work, ieducar-fpm, and ieducar-horizon running the queue worker with a restart policy.

Horizon is the Laravel queue dashboard and worker, and having it as a separate service is the right shape for a system that processes enrolments and report generation asynchronously.

The data services are postgres:18-alpine and redis:8-alpine, both with their ports published and configurable through environment variables, with a named volume for the database. The Redis prefix is ieducar- so that a shared Redis instance does not collide.

Nginx is nginx:1.30-alpine in front of fpm, publishing the HTTP and HTTPS ports, with the configuration and snippets directories mounted from docker/nginx. The compose file also has a pest service, which is the HTTP mock server Pest uses for tests, and it shares the same PHP image.

The stack is current rather than legacy, and the environment file shows the scale of the configuration surface. There are API access and secret keys, a legacy code and path setting that points at the older ieducar route prefix, Telescope disabled, Pusher credentials for websockets, a Honeybadger key for error reporting, a Google Tag Manager key, and S3 settings for file storage with a local filesystem disk as the default. The socket server variables for the websocket port are there as well.

For an operator, that is a lot of keys, and the ones that matter for a first deployment are the database, redis and mail settings.

The front end moved to Vite and Tailwind 4

The asset pipeline has been modernised, and the package.json shows how.

There are three scripts, build runs vite build, dev runs vite, and the dev dependencies are the Laravel Vite plugin, tailwindcss at 4.0.0 with the matching @tailwindcss/vite plugin, sass, vite at 8.0.0 and concurrently. The package is marked private and uses ES modules.

The interesting one is @laravel/multiplex as an optional dependency at 0.4.1. Multiplex is Laravel's mechanism for driving several dev servers at once, and it is optional because it is a development convenience rather than something the production build needs. With a stack that includes Horizon, websockets, a queue worker and a separate mock server for tests, having the ability to start the right set of processes together is more than a nicety.

The repository also has a vite.config.js at the root and a pint.json, so PHP formatting is handled by Laravel Pint rather than by a separate tool configuration, and phpunit.xml for the test suite.

The rest of the tree shows a conventional Laravel layout with app/, bootstrap/, config/, database/, public/, resources/, routes/, storage/, stubs/ and tests/, plus an ieducar/ directory that is presumably the legacy portion of the codebase, which is consistent with the LEGACY_PATH and LEGACY_CODE settings in the environment file.

The community channels and who actually supports the project

The communication section is written with unusual precision about who handles what, and it is worth reading because it tells you where to take a problem.

The belief stated is that the success of the project depends directly on clear and objective interaction between the members of the Community, and there is a code of conduct with good practices for that. The preference is for asynchronous communication channels where there is no need for real-time replies, because that makes the individual productivity of the project's contributors easier.

The channels are then split by purpose. The forum is for questions, discussions on how to install the platform, how to use features, support between community members and the community FAQ. GitHub issues are for new feature suggestions, bug reports and technical discussions. Telegram is for announcing news, mobilising the community and talking about topics that do not demand deep discussion.

And then the part that will save you time. Any other discussion group is not officially recognised by the i-Educar community and will not have support from Portábilis, the maintainer of the project.

That last statement is a deliberate boundary, and it is the sort of thing that usually goes unsaid. A project with thousands of users and a small maintainer team has to say where support ends, or the maintainers end up answering everything everywhere.

The contributing guide is pointed to for the detail on how the team works and the ways to help, and the installation and upgrade steps both live in their own documents, INSTALL.md and UPGRADE.md, with the FAQ hosted separately on the i-educar-website repository.

Editorial conclusion

Adopt i-Educar if you run a Brazilian public school network and need enrolment, attendance and reporting in one place, because it has been in production across the country since 2008 and carries the domain rules Brazilian municipalities actually work under. Skip it if you need a small school system you can read in an afternoon, since this is a large Laravel application with a long legacy path, and skip it if you are outside Brazil without a specific reason, since the domain, the fiscal reporting and the interface are all built for that context. Verify first which version you are on, since the default branch is 2.12 while the latest release is 2.11.0, and that your PostgreSQL and Redis versions are ones the compose file expects, since it pins them to specific major versions.

Frequently asked questions

What is i-Educar and who is it for?

It is a free school management system that is entirely online, allowing school secretaries, teachers, coordinators and managers to produce information and statistics in real time from a centralised database, reducing paper use, duplicated documents and citizen service time. It was developed by the Itajai city hall and published on the federal Public Software Portal in 2008 for the Education Secretariats and public schools of Brazil.

What modules or packages extend i-Educar?

Separate repositories from the same organisation cover digital pre-enrolment, reports, library, transport, and the Educacenso module for Brazil's national education census. Each is installed following the instructions in its own repository.

What does i-Educar need to run locally?

The docker compose file defines PHP 8.5 with Composer 2.10 in three services, one of which runs the Horizon queue worker, plus nginx 1.30-alpine, postgres:18-alpine and redis:8-alpine, with a pest service for the test mock server. The environment example lists the database, cache, queue, mail, Pusher, S3 and websocket settings.

Official sources

  1. License: GPL-2.0
  2. portabilis/i-educar on GitHub
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/portabilis-i-educar.svg)](https://hysenlabs.com/projects/portabilis-i-educar)

Was this useful?