I run a fairly advanced Morse Code translator website that converts plain text into Morse code and decodes Morse back into readable text in real time using JavaScript. The site also includes Web Audio API playback for dots and dashes, dynamic UI updates, clipboard integration, and optional message-sharing functionality. Recently, I migrated the hosting environment from a generic shared hosting provider to a Fedora-based VPS because I wanted more control over the server stack, security configuration, and deployment workflow. While the migration was successful overall, I’ve started encountering several issues related to Fedora, SELinux, Nginx permissions, and frontend performance that I haven’t been able to fully diagnose.
One of the main challenges involves SELinux and file access permissions. The Morse Code website is mostly static frontend code, but I also use a lightweight backend API for logging usage data and handling optional shared-message links. After deploying on Fedora, some API requests intermittently fail even though the services appear to be running correctly. Looking through logs suggests SELinux may be blocking certain access patterns between Nginx, the backend process, and file storage directories. I understand the importance of SELinux from a security perspective, so I’d prefer not to disable it entirely, but I’m struggling to determine the correct policies or contexts needed for a small web application like this.
Another issue relates to HTTPS and reverse proxy configuration on Fedora. I’m running Nginx with Let’s Encrypt certificates, and while the site generally works, I’ve experienced occasional redirect loops, WebSocket connection failures during testing, and strange caching behavior after updates. Since the Morse Code translator depends heavily on real-time interaction and instant frontend updates, these issues become very noticeable to users. I’m unsure whether the problems are caused by Nginx configuration, Fedora firewall defaults, SELinux restrictions, or a combination of all three.
Performance tuning has also become a concern. Fedora runs well overall, but when multiple users interact with the translator https://themorsecodetranslator.net/ simultaneously—especially when audio playback and rapid input updates are involved—I sometimes notice spikes in CPU usage or delayed response times from the backend API. The frontend translation itself is lightweight, but the site includes several JavaScript modules for audio timing and UI interaction, and I’m trying to determine whether there are Fedora-specific optimizations for serving interactive web applications more efficiently.
I’m also experimenting with containerized deployment using Podman because Fedora appears to integrate well with rootless containers. However, moving the Morse Code application into containers introduces additional complexity around networking, persistent storage, and SSL certificate access. Some parts of the setup work smoothly, but others become difficult to debug when combined with SELinux and reverse proxy rules. I’d appreciate insight into whether Podman is a good fit for a relatively small but interactive site like this, or if a simpler deployment approach would be easier to maintain.
Finally, I’d really appreciate guidance from Fedora users or administrators who host interactive JavaScript-heavy websites on Fedora Server. For a project like a Morse Code translator that relies on real-time browser interactions, audio APIs, and lightweight backend services, what stack or deployment approach would you recommend? I want to keep the site secure, performant, and maintainable while still taking advantage of Fedora’s security and containerization features without constantly fighting configuration issues. Sorry for long post!