Hello,

Thank you for sharing such an honest and insightful reflection on your journey developing FlyEnv. I truly empathize with the challenges you face, especially working solo and dealing with technical hurdles as well as community trust issues.

I believe FlyEnv is a very valuable project because it addresses the real needs of many developers who want a lightweight, fast, and easy-to-use tool for local development. Sometimes, these “small but mighty” solutions are exactly what help the community develop more efficiently alongside bigger tools like Docker.

Regarding trust and security concerns, this is indeed a significant barrier, especially when you don’t have organizational backing. But I believe that with transparency in your code, a loyal user community, and your positive engagement, FlyEnv can gradually build solid trust.

You might also consider calling on the community to help contribute toward the cost of obtaining a code-signing certificate — although it can be costly, this investment could help reduce false antivirus alerts, thereby increasing reliability and improving user experience for FlyEnv.

Finally, don’t worry too much about the comparison with Docker. Every tool has its place in the development ecosystem. FlyEnv’s strengths lie in simplicity and quick setup — something many people still need and appreciate.

I hope you keep your passion alive and continue to develop FlyEnv even better. If you ever need support or want to share more, I’m happy to help.

Wishing you good health and success!

I appreciate the honesty and will try to share mine.

"Why should we trust a Chinese developer?"

I'm happy to see a chinese fellow making his footprint and being internationally engaged in an awesome project. The code is open source and can be reviewed and compiled by anyone. I personally don't see your origins as a problem. Maybe I would think twice if there were proprietary parts in closed source.

Security Concerns by Design

I have no concerns as the design meets the natural use of it. If you need to run the code without system level access then let the user choose their setup during install:

[x] Local user only (%LocalAppData% and %AppData%) - Doesn't require sudo. Processes runs as %Username%
[ ] All users on the machine (%ProgramFiles% and %ProgramData%) - Processes runs as system - can be launched before logon.

False Positives in Antivirus Software

I assume this question comes from the use case with Kaspersky. That could be a one time case. Poor heuristic detection tech? It might not be an issue with other vendors. You can scan your files with Virustotal. That way be certain that they don't contain bad signatures from library exploits. Does any one have up to date pricing for signing licenses today?

It's not entirely a bad thing to rely on third party dependencies. But you need to make sure they are up to date. Libraries will have flaws at times. Keep them at minimal as they quickly grow fat.

Competing with Docker’s Dominance

I used Docker. I don't like it. I choose FlyEnv every day of the week and I love it. 🙂
I might choose docker if I worked a lot with temporary projects and deployments. It's possible to build a Docker manager UI if ppl want to run Docker instances with FlyEnv.

I come from the world of AMP stacks where FlyEnv is a natural selection. If I wanted to run 24 development websites. I don't want to run 24 docker instances with 24 apache daemons. For me FlyEnv is for stack management. While Docker is for stack isolation.

Is "passion" enough when costs (time, money) keep rising?

If you aim to raise income then premium extras might be a thing to roll out. But don't go the other way and block features people fell in love with. Or raise income from package installers, e.g. "charge WooCommerce a yearly fee for providing a WooCommerce installer".

Can trust barriers ever be overcome without institutional support?

Transparency is what I think keep trust level at high.

Does the world need another dev tool when Docker exists?

Yes, yes, and yes! And again, it's possible to add docker management as a thing.

Here are some ideas I had written down. I would love to hear some feedback on them.

Proposed project changes:

• Migrate project to Github Organization FlyEnv, FlyTech or similar.
• Move "FlyEnv Tools" to separate app (to get rid of a bunch of dependencies and shrink amount of code to maintain).
• Remove orphan libraries, and update existing ones. Get up to date, target ESM.
• Migrate to electron-vite (instead of using a bunch of seperates tscompile, esbuild, vite, electron-build, electron).
• Migrate to two package.json (https://www.electron.build/tutorials/two-package-structure.html).
• Migrate to IPC instead of deprecated nodeIntegration (both for security and future proof reasons).
• Separate the UI from the server process. Perhaps making them two separate apps "FlyEnv Server" and "FlyEnv UI". This would in the future enable FlyEnv to remote control a FlyEnv server. (Seems to go hand in hand with IPC after removing nodeIntegration) Run "FlyEnv Server" as "system" upon system boot and "FlyEnv UI" as "user".
• Merge Mac, Win, Linux branches to one and same. The current way has quickly left one another behind. Use if/switch conditions, separate imports, or separate directories for platform specific anomalies.
• Establishing dev branches for compatibility breaking updates: Branch "dev-feature" for x.X.x, Branch "dev-major" X.x.x).
• Use git amend instead of pushing same commit messages a zillion times. A git staging manager tool like SourceTree could be helpful.

Potential Premium upgrades:

• One click updates e.g. PHP 8.4.1 to 8.4.2
• Control more than one FlyEnv server remotely over TCP/IP socket. (Select which server from dropdown in the top left menu)
• Vhost template management

Be nice if this were in SettApp. Any chance of a bundled Wordpress? That would be your biggest market.