Linux API

2026-02-22 [1]

Today I focused on improving the installation experience for Linux-API.

I created setup and startup scripts to simplify deployment and reduce the chance of configuration mistakes. The setup script guides users through the installation process, while the startup script makes running the API predictable and convenient in both foreground and background modes.

Alongside the automation work, I wrote the complete project documentation. It now includes:

• a fully automated setup path
• a detailed manual setup guide (recommended)
• step-by-step server preparation instructions

The manual setup is recommended because it provides better transparency, helps users understand the system, and makes debugging easier if something goes wrong.

Additionally, every configuration option is now documented. Each environment variable and setting is explained so administrators can confidently customize deployments for their own infrastructure.

With deployment streamlined and documentation in place, I consider the project functionally complete for now. The current state is stable, understandable, and ready for real-world use.

I’m calling this milestone done — time to ship 🚀

Changelog

• Add config options wiki link to some wiki pages
• Add configuration documentation
• Edit config default values
• Update documentation link in README
• Small doc update
• Add start script
• Add automate setup wiki page
• Add setup script
• Add wiki home page
• Correct README documentatin link
• Update README
• Add manual setup wiki page

2026-02-21 [1]

Today I added a new feature that allows routes to be disabled directly through the configuration. This makes it easy to control access to specific endpoints without modifying the codebase, which is especially useful for maintenance, staged rollouts, or demo environments.

I also started rewriting the documentation from scratch because the previous version was outdated. I am currently working on making the setup process clearer and ensuring the API is easy to understand and use.

Changelog

• Add proper route access JSON response
• Fix route access not being applied
• Add route disable or enable logic
• Fix CORS not being applied
• Fix CORS beeing not applied
• Add devlog 2026-02-19_1

2026-02-19 [1]

I focused on performance improvements and infrastructure stability in this update.

Database Optimization

I significantly accelerated database performance by introducing proper indexing. Queries that previously required full table scans are now resolved much more efficiently, reducing latency and CPU load.

Pgpool Integration with Caching

Pgpool is now integrated directly into the Docker Compose setup with caching enabled. This allows frequently requested data to be served faster without repeatedly hitting the database.

Performance Improvements

These two changes together resulted in a major performance boost.

Previously, a ZAP scan would generate enormous load on the system. During heavy scans, response times could spike to up to 10 seconds.

Now, even under very high load, response times rarely exceed 600 ms.

Stability & Release Update

The dev version has been merged into main, as it now feels reliable and production-ready.

Documentation Rewrite

Outdated documentation was removed to avoid confusion.

Changelog

• Merge pull request #20 from Ivole32/dev
• Remov old documentation
• Revert “Add performance libs”
• Add performance libs
• Sanitize malformed route input to avoid flush worker failure
• Prevent flush worker failure when logging routes containing null bytes
• Fix pgpool connection issues
• Update docker-compose.yml
• Fix for error with authentificatio using SCRAM
• Fix pgpool connection issues
• Improve PostgreSQL connection setup
• Performance update

2026-02-18 [2]

Devlog — Metrics & Health System Completed

Today I completed the implementation of the API’s metrics and health monitoring system. The goal was to improve production observability and detect failures, performance regressions, and infrastructure issues quickly.

The system now collects request metrics, response times, and status code distributions. Aggregated data is periodically flushed into TimescaleDB for efficient time-series storage and long-term analysis. I also added flush worker health tracking, exposing success rates, error counts, consecutive failures, and timestamps of the last successful run.

New monitoring endpoints now expose:

• flush worker health and error rates
• database readiness and migration state
• route performance metrics and status code distributions
• global request statistics and error rates

These endpoints provide valuable operational insight and make production debugging significantly easier.

After finishing, I ran a stress test with OWASP ZAP. That’s when I realized performance wasn’t as great as expected. Naturally, I increased the number of Uvicorn workers.

Everything immediately broke.

Multiple workers do not play nicely with the in-memory aggregation and flush process. Watching the metrics system fight itself was… educational.

For now, run the API with a single worker. I currently have zero motivation to debug multi-worker synchronization chaos.

Next Steps

• Verify monitoring endpoint correctness and stability
• Validate metrics accuracy under sustained load
• Perform a comprehensive performance optimization pass
• Revisit multi-worker support (when motivation returns)

Despite the chaos, the observability foundation is now in place — and that’s a big step forward.

Changelog

The full changelog exceeded the character limit

• Full changelog

2026-02-18 [1]

Monitoring & Observability Progress

Today I focused on improving the operational visibility of the API. The goal is to introduce monitoring and health endpoints that make it easy to detect problems quickly in production and understand system behavior under load.

A major milestone was laying the foundation for persistent metrics storage. I finalized the initial database structures for metrics and integrated TimescaleDB to efficiently handle time-series data, providing a scalable backbone for performance data and trends.

I also worked on routes to expose database health information and detailed API usage statistics. These endpoints will help inspect request metrics, error code distributions, and overall system health for faster debugging in production.

I haven’t committed most of this work yet, as I’m still refining the implementation before pushing it to the repository.

Although work remains, today marked strong progress toward a more observable system. I am wrapping up after a long session, but the core groundwork is now in place.

Next Steps

• Implement monitoring endpoints for API health and metrics
• Expose database health status and connection pool state
• Provide detailed statistics for request performance and error codes

Overall, a productive day with meaningful progress toward production-ready monitoring.

Changelog

• Clean up user_database
• Implement healthcheck for Postgresql pool connections
• Add metric tables through migration
• Add postgresql timescaledb extention
• Add more docstring documentation
• Add missing docstrings for user_database
• Fix typos and rename misspelled exceptions/config constants
• Added devlog 2026-02-17_1

2026-02-17 [1]

Today I focused on improving compatibility and maintainability by migrating the old system statistics routes from the legacy routing layer into the v1 API.

Migration of Legacy Statistics Routes

I moved the existing system statistics endpoints from the legacy routes into the v1 structure. Fortunately, this process was straightforward:

• The legacy implementation was already well-structured
• Performance was still solid and efficient
• Only minimal adjustments were required to match the v1 routing conventions

Because the original codebase was clean and modular, the migration did not introduce regressions or performance issues.

Configuration Toggle for Legacy Routes

After completing the migration, I added a new configuration option that allows enabling or disabling legacy routes.

New config option:

• Toggle legacy routes on/off
• Provides flexibility during transition and testing
• Allows gradual deprecation without breaking compatibility

This addition makes it easier to phase out legacy functionality while maintaining backward compatibility when needed.

Next Steps

Next, I plan to implement dedicated health endpoints and supporting middleware to improve system maintainability and enable more efficient debugging and monitoring.

Changelog

• Config option to enable/disable legacy routes
• Fixed missing import of system info router
• Implemented system info router in v1
• Improved loggign for system load endpoints
• Renamed system_router to system_load_router
• Implemented system load routes in v1
• Renamed load_monitor service to legacy_load_monitor
• Added devlog 2026-02-16_1

2026-02-16 [1]

In this development cycle, I focused primarily on identifying and fixing bugs, especially within the user management routes. Several edge cases and unintended behaviors surfaced during testing, particularly around user deletion, role changes, and state transitions. Resolving these issues significantly improved the stability and predictability of the system.

While reviewing safety concerns, I intentionally skipped implementing protections against self-destructive actions for now. The following note reflects that decision:

“To prevent these scenarios, I will implement safeguards to block self-destructive actions in the next iteration.”

I chose to postpone this because it did not feel critical at the current stage of development and would have slowed down progress on more immediate stability fixes.

With the most disruptive bugs addressed, the next step is to begin migrating the core system statistics logic from the legacy API routes. During this process, I plan not only to port the functionality but also to refactor and improve it to better fit the current architecture and performance goals.

Next focus:

• Port system statistics logic from legacy routes
• Refactor and optimize the implementation
• Ensure consistency with the new API structure

This marks the transition from stabilization work to enhancing core functionality.

Changelog

• Fixed null returns for activate/deactivate endpoints
• Fixed null return when changing user role
• Possible fix for 500 error when loading non-existing user perm record
• Fixed 500 error when updating user perms
• Possible fix for database flush issues
• Possible fix for database flush issues
• Added devlog 2026-02-15_1

2026-02-15 [1]

Today I implemented new endpoints for managing user states and permissions.
Admins can now:

• activate users
• deactivate users
• change user roles (admin ↔ non-admin)

While working on these features, I realized that administrators could potentially sabotage themselves, for example by:

• removing their own admin privileges
• deactivating their own account
• accidentally deleting critical accounts

To prevent these scenarios, I will implement safeguards to block self-destructive actions in the next iteration.

To ensure system integrity and protect critical accounts, I introduced an immutable attribute to the user database. When a user is marked as immutable:

• the account cannot be deleted
• the account cannot be modified
• critical permissions cannot be changed

This guarantees that the main administrator account remains protected and that essential system access cannot be lost.

These changes significantly improve the safety and robustness of the user management system.

Changelog

• Fix for 500 error when deactivating yourself
• Possible fix for 500 error for chaning user’s role
• Fix for error when creating default admin user
• Fixed non default immutable attribute for admin user
• Fix for error with api_key
• Fix for errors with admin creation
• Implemented more user management routes + Added immutable user(s)
• optimize performance for legacy and v1 routes
• Added devlog 2026-02-14_2

2026-02-14 [2]

Today I started auditing the existing user management routes to identify bugs and potential security issues.

For this process I used OWASP ZAP. From past experience, its automated scanning is very effective at uncovering edge cases, malformed requests, and improper error handling.

During testing I discovered that the user deletion endpoint accepted arbitrary strings instead of strictly validating UUIDs. Supplying invalid values caused database errors due to failed UUID parsing. Input validation has now been tightened to ensure only valid UUIDs (or the special "me" value) are accepted.

Additionally, I rediscovered an old host-header parsing issue that I had previously reported but which was not accepted upstream.
Issue reference: https://github.com/pallets/werkzeug/issues/3063

To prevent crashes caused by malformed host headers, I implemented a manual mitigation in the middleware layer.

Next Steps

• Continue the security review of existing endpoints
• Improve error handling to safely manage malformed requests
• Continue implementing new API routes in parallel with the hardening work

Changelog

• Feat: Fix for pallets/werkzeug#3063
• Feat: Fix for pallets/werkzeug#3063
• Fix for pallets/werkzeug#3063
• Hardened pydantic models
• Addede devlog 2026-02-14_1

2026-02-14 [1]

Added a new /users endpoint that allows administrators to retrieve a complete list of registered users.

This endpoint is protected by admin permission checks and includes pagination support to ensure performance and prevent large response payloads. Rate limiting has also been applied to reduce potential abuse and protect system resources.

Highlights

• Admin-only access control
• Paginated responses for scalability
• Rate limiting for stability and abuse prevention
• Prepared for future filtering and search capabilities

This addition improves system management by giving administrators a clear overview of all users while maintaining performance and security.

Changelog

• Fixed 500 error for admin /users endpoint
• Fixed server crash because of incorrect import
• Fixed “GET/HEAD method cannot have body.”
• Implemented /users endpoint for listing users as admin
• Added devlog 2026-02-13_1

2026-02-13 [1]

Added User Endpoints to v1 Router

Today I added two new endpoints to the v1 router to improve user self-management:

• /me — allows authenticated users to retrieve their own account information
• /delete — allows users to delete their own account

These endpoints are intended to simplify common user actions and prepare the API for more structured account management.

Issues Encountered

During implementation I ran into several problems that were difficult to diagnose. Because the current logging is minimal, I was unable to clearly identify the root causes of some failures and unexpected behaviors.

Next Steps

In the coming days I plan to:

• improve logging and error visibility across the API
• continue building additional user management routes
• migrate legacy routers related to system statistics into the new structure

These steps should improve maintainability, observability, and overall API consistency moving forward.

Changelog

• Fix for 500 error when deleting user as admin
• Possible fix for 500 error when deleting user
• Added logging to user routers to find cause of 500 error when deleting users
• Fixed 500 error when deleting user
• Added user delete route to v1 routers
• Cleand up /me endpoint return values
• feat: 12f7e2f Second try
• Fixed 500 error for /me endpoint
• Implemented Demo API key file
• Possible fix for no admin account creation error
• Fix for 500 internal server error when authentificating
• Implemented /me endpoint

Devlog 2026-02-11 [1]

New auth system for v1 routes

In the past few days, I started implementing the new auth dependencies for the new v1 routes.

Current Implementation

I was able to implement the auth functionality into the only existing route for the v1 API version (currently in development).

Issue with Demo Mode Admin API Key

I faced issues when trying to show the default admin API key in demo mode. The bug was that my FastAPI auth dependency was generated before the default API key was created and set as static.

Fix

After I found that out, I was able to fix it easily.

Next Steps

Next, I’ll implement more user management endpoints in v1.

Changelog

• Every commit was to big for the devlog => Full Changelog

Devlog 2026-02-5 [2]

Devlog - Legacy Endpoint Warning Middleware

I added a custom middleware that detects requests to legacy API endpoints and adds a warning flag to the response headers. This helps clients recognize when they are calling routes that still rely on the old database layer.

Changes

• Implemented a custom FastAPI middleware
• Middleware checks requests against the legacy API prefix
• Automatically adds deprecation headers for legacy routes

Purpose

The goal is to clearly signal that certain endpoints are still using the legacy database logic and are not connected to the new v1 database system. This supports the ongoing migration.

More legacy routes will be migrated step by step.

2026-02-5 [1]

Devlog – PostgreSQL Migration & API Refactor

Today I continued integrating the PostgreSQL database system into the active backend. The PostgreSQL layer itself was already developed in earlier devlogs. This session focused on connecting it to the running API, starting with the registration flow.

Progress

• Connected the PostgreSQL system to the backend
• Started integrating it into the registration endpoint
• Began rebuilding API routes to use the new database system

Legacy Compatibility

• The old SQLite3 database functionality is still included (no sync to new database)
• Existing SQLite-based endpoints are kept as legacy API routes
• Legacy routes remain functional as fallback
• New PostgreSQL routes are being built in parallel
• Migration is happening step by step to avoid breaking changes

Issues Encountered

• Some queries failed due to schema and type differences
• Constraint handling caused unexpected errors
• Multiple migrations produced schema conflicts/bugs

Current Status

• PostgreSQL connection is working
• Registration route migration is in progress
• Legacy SQLite routes are still active
• New PostgreSQL-based API routes are partially implemented

Next Steps

• Continue rebuilding API routes for PostgreSQL
• Gradually replace legacy SQLite endpoints
• Improve database validation and error handling

Devlog 2026-02-1 [1]

Devlog - Database System Refactor & Error Handling Improvements

Today I continued working on the new database system and focused on stabilizing the overall structure and reliability.

✅ Database Layer Progress

I expanded and refined the new database access layer. The repository-style methods for user records, authentication data, and permission management are now more consistent and better structured. Query execution and transaction handling were reviewed and cleaned up.

✅ Improved Error Handling with Custom Exceptions

I significantly improved error handling by introducing dedicated custom exception classes across the database and service layers. Instead of using generic exceptions, the code now raises domain-specific errors, which makes debugging and API responses much clearer and more predictable.

This includes cases such as:

• user not found
• permission record missing
• last admin protection
• creation and deletion failures
• permission update failures

✅ Full Documentation Added

I wrote complete docstrings for the entire new database functionality. All core database methods are now documented with:

• purpose
• arguments
• return values
• raised exceptions

This should make future maintenance and extension much easier.

✅ Dependencies Updated

Project dependencies were updated to the newest compatible versions to ensure current features, security fixes, and long-term support.

🔜 Next Steps

Based on current progress, I expect to integrate and test the new database system tomorrow or the day after tomorrow.

2026-01-31 [2]

Devlog – Database Initialization Fix and Migration Cleanup

🛠 Fixed PostgreSQL Initialization Issue

I fixed an issue where the PostgreSQL database was not being created automatically when starting the Docker container. The initialization process has now been corrected to ensure that the required database is reliably created during container startup. This improves the setup process and prevents manual database creation steps.

🧹 Migration Code Cleanup

I also removed outdated and unnecessary migration code from the new database structure. This cleanup helps reduce technical debt, improves maintainability, and ensures that the migration system remains clean and easier to manage moving forward.

🗄 Continued Work on the New Database System

Development on the new database architecture is still ongoing. Several core functionalities still need to be implemented before the system is fully ready. I am currently working on expanding these features, improving stability, and preparing the database for integration into the production system. Further testing and optimization are in progress to ensure a smooth transition.

🚀 Next Steps

The focus now is on finalizing the remaining database features and preparing the implementation for deployment into the live environment.

2026-01-31 [1]

Automatic Migrations, Backups and Migration Logging

✅ Automatic Database Migrations

I have successfully implemented a fully automatic database migration system.
The system now detects schema changes and applies migrations without requiring manual intervention. This significantly reduces setup time, prevents version mismatches, and ensures that all environments remain synchronized.

The migration process has been designed to be safe and consistent, making it easier to deploy updates and maintain database integrity across development and production environments.

💾 Automatic Backup System

Alongside automatic migrations, I implemented a reliable backup system that runs automatically before migrations are executed.

This ensures that:

• The database state is preserved before any structural changes are applied
• Recovery is possible in case of migration failures
• Data integrity risks are minimized

The backup process is fully integrated into the migration workflow and requires no manual interaction.

📊 Migration Logging System

A persistent and reliable migration logging system has now been added to the database.
This system records detailed information about every migration attempt, including:

• Migration direction (upgrade/downgrade)
• Target revision
• Execution status (success or failure)
• Error information when failures occur
• Timestamp of execution

This logging infrastructure provides full transparency and traceability for database changes and greatly simplifies debugging and maintenance.

🚀 Summary

With these features implemented, the database management system is now significantly more robust and production-ready. Automatic migrations, integrated backups, and detailed migration logging together provide a safe and maintainable workflow for future development.

2026-01-25 [3]

Progress on Database Migration System and Automatic Backups

I continued working on the migration logic of the new database system.

The main focus is currently on implementing reliable backup functionality and automatic database migrations using Alembic. The goal is to ensure that schema changes can be applied safely, while minimizing the risk of data loss by creating backups only when migrations are actually required.

While the core functionality is coming together, I am still running into some difficulties regarding overall code design decisions. In particular, deciding where certain responsibilities should live (for example, how much logic belongs in startup code versus dedicated database or service classes) is proving to be non-trivial.

For now, the priority is correctness and safety over perfect structure. Once the migration and backup flow is stable, I plan to revisit and refine the architecture to make it cleaner and more maintainable.

2026-01-25 [2]

Devlog - January 25, 2026

Started implementing backup and migration functions directly in the code.
The goal is to make database upgrades safer and more automated without relying solely on the CLI.

Tomorrow, the plan is to attempt integrating the new PostgreSQL database system into the existing codebase and ensure everything works with the updated setup.

Devlog 2026-01-25 [1]

Devlog: Implementing PostgreSQL Database Migrations with Alembic

Today I spent some time setting up database migrations for our PostgreSQL backend using Alembic.

The main goal was to streamline the development process for our new database system, which currently can only be tested after committing changes on my Linux server. By integrating Alembic migrations, I can now:

• Keep track of schema changes in a structured way
• Apply updates to the database reliably without manual intervention
• Simplify testing and deployment, reducing errors caused by manual schema updates

This setup should make future development much faster and safer, especially when iterating on new models and schema modifications.

Devlog 2026-01-23 [1]

I continued restructuring the project by moving files into more appropriate and maintainable folder structures.
Alongside this, I kept improving code documentation to make the codebase easier to understand and work with.

This ongoing cleanup aims to improve overall project organization, readability, and long-term maintainability.

Devlog 2026-01-18 [2]

This is a small interim update reflecting recent committed changes.

I continued working on improving the structure and readability of the codebase, with several refactors now fully committed to keep the project cleaner and easier to maintain.

Development on the new PostgreSQL database implementation is also progressing. The database setup and related changes have been committed, but the new database is not yet integrated into the main application.

Additionally, I worked on general organization and cleanup tasks. More functionality and behavior are now configurable via the config files, improving flexibility without requiring code changes.

This update focuses on internal improvements and preparation for future features rather than a full release.

Devlog 2026-01-18 [1]

I decided to continue my old SoM project called Linux API as part of the Flavortown competition.

Since working on the original version of Linux API, my technical skills and my approach to clean and maintainable software design have improved significantly. Because of this, my current focus is not on adding new features yet, but on refactoring, cleaning up, and restructuring the project.

Project Cleanup and Refactoring

At the moment, I am going through the project and removing outdated or unnecessary parts to bring the codebase up to my current standards.

So far, I have:

• Completely removed the old pippackage from the repository

• Updated the versions in the requirements file to use more recent and supported dependencies

• Started redesigning the folder structure to make the project clearer and easier to maintain

• Begun improving the documentation alongside the structural changes

This cleanup phase is important to reduce technical debt and ensure the project is easy to work on in the long term.

New Database System

In parallel, I am working on a new database system using PostgreSQL. Instead of modifying the old data layer, I decided to redesign the database from scratch with a cleaner schema and better scalability in mind.

I am currently designing the tables and their relationships.
An image showing the current database table structure is attached to this update.

Next Steps

Right now, the focus is on finalizing the new folder structure, improving documentation, and finishing the database design. Once this foundation is solid, I will move on to rebuilding and extending features on top of it.

More updates coming soon.