Atheos: a browser IDE you install by copying a folder

The problem Atheos targets: an editor without a desktop install

Atheos is for people who want to edit code in a browser tab on a machine they control. The README frames the goal as a cloud IDE with a small server footprint, expanding on Codiad's stated intent of fast, interactive development without the overhead of larger desktop editors. That is a narrower claim than most IDE projects make. It is not trying to replace a full desktop environment. It is trying to be the thing you point a browser at when you have a server, a web root, and no appetite for installing an editor on every machine you work from.

The audience follows from that. A developer with a Debian LAMP server who wants a shared editing surface. Someone who needs a web-accessible editor on a box that already runs PHP. The repository topics list cloud-ide, editor, ide and self-hosted, which matches the README's framing. If your workflow assumes a local language server, a debugger attached to a running process, or an extension marketplace, this project is not addressing that problem.

What changed in the fork from Codiad

The README states Atheos has been completely rewritten from the original Codiad project to use more modern tooling and cleaner code. It lists the notable changes explicitly: a move from GET requests to POST requests to the server, a new UX and theme, a more complete user permission system, a reduction in repeated traffic between server and client, complete removal of jQuery and its plugins, and built-in Git integration.

Those items are worth reading as a description of a maintenance fork rather than a new architecture. The GET-to-POST change is a security-relevant adjustment, since state-changing operations over GET are easy to trigger from a link. Dropping jQuery matters for bundle size and for how plugins are written. The permission system is the item with the least detail in the README; it says the system is more complete than Codiad's but does not enumerate roles, scopes or defaults, so anyone whose decision hinges on permission granularity has to read the source or the in-app admin screens.

The README also claims a strong emphasis on standardized components and modules to make plugin development easier. That is a claim about internal consistency, and the contributing section repeats it: understanding one component is meant to carry over to the others. Treat it as a design intention stated by the maintainers, not as a verified property of the codebase.

How the install actually works

The README gives one manual path. Place Atheos in a web accessible folder, point your browser at it, and the installation screen runs. Before that, five paths must be writable by the web server: /config.php, /data, /workspace, /plugins and /themes. The README states the system alerts you on the installation screen if dependencies are not met, so a misconfigured permissions set surfaces as an install-time warning rather than a silent failure later.

The README notes the project is primarily developed against a Debian LAMP Server and asks users on other stacks to report installation issues. That is a direct statement that other stacks are less tested. If you run nginx with php-fpm, or a container base image that is not Debian-derived, you are outside the configuration the maintainers describe as their primary one.

There is a Docker path as well. The README points to a DockerHub image under hlsiira/atheos. It gives no tag names, no environment variables, no volume mapping and no compose example, so the image is referenced but not documented in the README itself. Anyone going that route is reading the DockerHub page instead.

The upgrade process is a manual file copy, by design

Atheos has a built-in update check system but no mechanism for performing the update. The README says this plainly: the system relies on the admin to copy the files, and the update system is currently being rewritten. That sentence is the most consequential limitation in the whole document.

The documented procedure is to delete everything except /config.php, /data, /workspace, /plugins and /themes, or move those folders to a new directory. Then navigate to /themes and delete the default folder. Then download the newest version from the GitHub repository and extract it into the root of the installation. Then confirm the same five paths still have write capabilities.

Three things follow from that. First, an upgrade is a destructive operation on the application tree, so a backup of the preserved folders is the only rollback path the README implies. Second, deleting /themes/default is a required step, which means a theme you have customised under that name is gone. Third, because plugins and themes live outside the replaced tree, a major version bump can leave a plugin written against an older internal structure still present and still loaded. The README's claim that standardised components make plugin development easier is about writing plugins, not about their survival across upgrades.

The release history supports the point about cadence. v5.5.0 is dated October 2022 and v601 is dated January 2025, with the repository's last push recorded in August 2026. The gap between those two releases is more than two years, so the manual upgrade is not a weekly chore. It is an occasional one that you will have to reconstruct from the README each time, because there is no in-app flow to walk you through it.

Licence and maintenance cost

The README carries an MIT licence badge linking to opensource.org. The repository metadata supplied here reports the licence as unknown. Those two signals disagree, and the disagreement is the thing to resolve before you depend on the project. Check for a LICENSE file in the tree you actually download rather than trusting either the badge or the metadata field. Nothing here is legal advice; if the licence status of a dependency matters to your organisation, read the file.

Maintenance cost is mostly operational rather than financial. You are maintaining a PHP web application that writes to five paths your web server user must own. Every upgrade re-tests those permissions. The plugin and theme folders are preserved across upgrades, which means their compatibility with a new core version is your problem, not the installer's. The built-in update checker tells you a new version exists; it does not move you to it.

There is also a documentation cost. The README states that more information on the update system will be provided later, and that the update system is being rewritten. Until that lands, the README's numbered steps are the whole procedure.

Where Atheos is the wrong tool

Pick something else if the browser is not the point. A self-hosted editor that runs in a tab and writes to a server directory is a different product from an editor that runs locally and syncs, and the README does not claim to be the latter. If your team already standardises on a desktop editor with a shared configuration, adding Atheos means maintaining a second editing surface with its own permission model and its own upgrade ritual.

Pick something else if you need an upgrade path you can automate. The README is explicit that no such path exists today. A scripted deployment that replaces the application tree and preserves five named paths is something you would write yourself, and the README does not describe one.

Pick something else if you are not on the stack the maintainers develop against. The README says Debian LAMP is the primary environment and invites reports from other stacks. That is an honest statement of where testing happens, and it should inform the decision rather than be read past.

For a comparison, consider a desktop editor paired with a remote filesystem mount. That approach keeps the editor process on your machine and treats the server as storage. Atheos inverts it: the editor runs on the server and the browser is the client. The trade-off is direct. You get a zero-install client and a single place where permissions are enforced. You give up local tooling, and you accept that the server is now in the edit loop for every file operation. Neither approach is strictly better; they fail in different ways.

Who should adopt it and what to check first

Adopt Atheos if you have a Debian LAMP server, you want a browser-based editor with a small footprint, and you are willing to treat upgrades as a documented manual procedure. The install is genuinely short: drop the files in a web root, make five paths writable, open the browser. The built-in Git integration and the removal of jQuery are concrete differences from the Codiad the README describes.

Do not adopt it if you need an in-app upgrade, if you run a stack outside the one the maintainers name, or if you cannot keep the five writable paths writable across your deployment tooling.

Before you commit, verify three things. Confirm a LICENSE file exists in the downloaded tree, because the metadata and the README badge disagree. Read the v601 release notes, since the README says the update system is being rewritten and the notes are where that work would appear. And read the permission system in the admin screens rather than the README, because the README calls it more complete than Codiad's without describing what the roles actually are. If all three check out for your environment, the install cost is a folder copy and the ongoing cost is a folder copy per release.

Editorial conclusion

Adopt Atheos if you want a small self-hosted editor on a Debian LAMP box, you are comfortable with a manual file-copy upgrade, and you can keep /config.php plus the data, workspace, plugins and themes folders writable by the web server. Do not adopt it if you need a supported in-app upgrade path, a documented licence file in the repository, or a stack other than the one the maintainers develop against. Verify two things before you commit: that a LICENSE file exists in the tree you download, since the repository metadata reports the licence as unknown while the README badge says MIT, and that the v601 release notes describe the update mechanism you intend to use, because the README states the update system is being rewritten.

Official sources

1. Atheos/Atheos on GitHub
2. Issues
3. Project website
4. README
5. Releases