Impossible to start #16
Replies: 11 comments 9 replies
-
|
Hey @CorwinRail, thanks for reporting this! You caught a nasty bug that was completely blocking new installations. Just tracked this down and fixed it. The issue was actually two separate problems that made it look like nothing was working: What was happening: The nself build command was getting stuck in an infinite loop when trying to generate SSL certificates. It would just sit there showing "⠋ Generating SSL certificates..." forever. This happened because our SSL library was trying to call logging functions that created a circular dependency - basically the SSL code needed env.sh, which needed display.sh, which tried to call back into functions that weren't loaded yet. Classic circular import problem. Since the build never finished, you never got your docker-compose.yml file, which explains why start wouldn't work either. This was related to a very recent SSL improvement that was made. The fix: I switched the build process to use a simpler, direct SSL generation method that doesn't have those dependencies. Also cleaned up a similar issue in the compose generation script where log_info calls were causing the same kind of loop. The specific changes:
Testing it: Just ran through the full flow on a fresh directory and it's working smoothly now: Really appreciate you testing across multiple OSes - that helped confirm it wasn't platform-specific. The fix is pushed to main (commits 39e2b85 and 7bae067) and should resolve it on all your test systems. Let me know if you run into any other issues! This was a critical blocker and I'm glad we got it sorted. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately still a problem. Please see what happens [arek@localhost rail]$ nself build ╔══════════════════════════════════════════════════════════╗ ╔══════════════════════════════════════════════════════════╗ when I run nself doctor I get [arek@localhost rail]$ nself doctor ╔══════════════════════════════════════════════════════════╗ System Information System Requirements Network & Connectivity nself Configuration Database Health Even when I manually run ../.nself/src/services/docker/compose-generate.sh its creating docker-compose.yml but when I try to run nself start this is only what I get [arek@localhost rail]$ nself start ╔══════════════════════════════════════════════════════════╗ Docker is showing no running containers [arek@localhost rail]$ docker ps I used docker compose pull to download containers |
Beta Was this translation helpful? Give feedback.
-
|
Hey @CorwinRail, Found and fixed the issues! There were actually two problems:
Just pushed fixes (commit 42f55b5):
Pull the latest and give it another try: Let me know if this resolves it for you! |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately its not creating docker-compose.yml and next steps fail [arek@localhost rail]$ ls -la ╔══════════════════════════════════════════════════════════╗ arek@localhost rail]$ nself start ╔══════════════════════════════════════════════════════════╗ |
Beta Was this translation helpful? Give feedback.
-
|
Hey @CorwinRail, I've added some additional safety checks and diagnostics to help with your situation (commit 6868011):
Pull the latest and give it another try: If you're still not seeing docker-compose.yml being created, could you share:
nself should work with a blank .env file using smart defaults, but there might be something specific to your environment or configuration that we need to identify. The debug output will show us exactly what the build process is detecting. Let me know what you find! |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately no succses (this is Rocky Linux) Same issue on Ubuntu [arek@localhost rail]$ more .env ╔═══════════════════════════════════════════════════════╗║ LOCAL DEVELOPMENT CONFIGURATION ║╠═══════════════════════════════════════════════════════╣║ Personal settings - Override defaults as needed ║║ This file is git-ignored for your safety ║╚═══════════════════════════════════════════════════════╝Uncomment and modify only what you need to changeAll settings use smart defaults from nselfCore Settings (usually customized per developer)PROJECT_NAME=my-appBASE_DOMAIN=local.nself.orgENV=devService Ports (if defaults conflict)POSTGRES_PORT=5432HASURA_PORT=8080HASURA_CONSOLE_PORT=9695MINIO_PORT=9000MINIO_CONSOLE_PORT=9001REDIS_PORT=6379MAILPIT_UI_PORT=8025Optional Services (uncomment to enable)REDIS_ENABLED=trueFUNCTIONS_ENABLED=trueNSELF_ADMIN_ENABLED=trueMLFLOW_ENABLED=truePROMETHEUS_ENABLED=trueGRAFANA_ENABLED=trueDevelopment PreferencesHASURA_GRAPHQL_ENABLE_CONSOLE=trueHASURA_GRAPHQL_DEV_MODE=trueAUTO_FIX=trueCOMPOSE_PROJECT_NAME=${PROJECT_NAME}Custom Services (examples)SERVICES_ENABLED=trueNESTJS_SERVICES=api,workersGOLANG_SERVICES=analyticsPYTHON_SERVICES=ml-service[arek@localhost rail]$ export DEBUG=true ╔══════════════════════════════════════════════════════════╗ |
Beta Was this translation helpful? Give feedback.
-
|
Hey @CorwinRail, I need more information to diagnose what's happening on your Rocky Linux system. I've created a debug script to help us figure this out. Please run the following: First, make sure you have the latest version Download and run the debug script Or if you prefer to run it locally: This debug script will check:
Please share the full output. This will help us identify if it's:
The build command should definitely be creating docker-compose.yml - we just need to see what's preventing it on your system. |
Beta Was this translation helpful? Give feedback.
-
|
This is fresh installation of linux only to test nself. Keep in mind that containers I downloaded manually - thats why it shows 18/19 === nself Build Debug Script === === Environment Check === === nself Installation Check === === Directory Contents === === .env File Check === === Docker Check === === Direct Script Execution Test === === Running Build with Debug === ╔══════════════════════════════════════════════════════════╗ === Post-Build Check === === Debug Complete === |
Beta Was this translation helpful? Give feedback.
-
|
This is a test from Ubuntu. Fresh server too. === nself Build Debug Script === === Environment Check === === nself Installation Check === === Directory Contents === === .env File Check === === Docker Check === === Direct Script Execution Test === === Running Build with Debug === ╔══════════════════════════════════════════════════════════╗ === Post-Build Check === === Debug Complete === |
Beta Was this translation helpful? Give feedback.
-
|
Hey @CorwinRail! I think I got it fixed this time. This was a sneaky one that had me scratching my head for a bit. Turns out Linux bash is way stricter than macOS bash when it comes to undefined variables. When your Rocky/Ubuntu systems hit an undefined BASE_DOMAIN variable, bash just silently quit - no error, no message, nothing. That's why you saw "Configuration validated" and then... crickets. On my Mac, it just kept chugging along, so I never caught it during development. The fix: I've added proper defaults for all variables (like ${BASE_DOMAIN:-localhost}) and error traps that actually tell you what broke instead of ghosting you. To test: Should work now - you'll finally get that docker-compose.yml generated. This was a classic "works on my machine" moment that reminded me why I need better cross-platform testing. Linux bash was actually doing the right thing according to POSIX standards - Mac was just being too nice to me! Let me know if it works now. If not, at least the new error traps will tell us exactly what's failing. You caught me in the middle of preparing to refactor the build.sh and other commands as we prepare for a more stable release schedule for v0.4+ so absolutely perfect timing. Thanks for your patience on this one! |
Beta Was this translation helpful? Give feedback.
-
|
unfortunately not working. Tested on Rocky and Ubuntu. We will finally solve it :) Keep in mind that most of your potential users and customers will run it on Linux . [arek@localhost rail]$ nself build ╔══════════════════════════════════════════════════════════╗ |
Beta Was this translation helpful? Give feedback.
-
|
Hey @CorwinRail, I've pushed another round of fixes with additional safety checks. Found a few more Linux-specific edge cases that could cause the script to fail silently. Additional fixes in this update:
The confusing part for me was that I also use nself on an Ubuntu VPS without any issues, which made this harder to track down. It turns out the problem only manifests in certain shell contexts. If still having issues, run with debug:
The script now has much better error handling and should work even in restricted shell environments. If it still fails, the debug output will show exactly where it's stopping. Each of these Linux compatibility issues is making nself more bulletproof, so thank you for your patience in helping track this down! |
Beta Was this translation helpful? Give feedback.
-
|
No success :( It looks like it stop working after validation. I tested on Mac and there its building properly and even starting. Rocky Linux Ubuntu ╔══════════════════════════════════════════════════════════╗ |
Beta Was this translation helpful? Give feedback.
-
|
Hey @CorwinRail, Think I found it - the issue was ((variable++)) arithmetic operations causing silent exits on Linux when the value is 0. With set -euo pipefail, this makes the script exit immediately after validation. Fixed all instances to use variable=$((variable + 1)) instead, which doesn't trigger the exit. Could you try pulling and testing? Let me know if this finally fixes it for you! |
Beta Was this translation helpful? Give feedback.
-
|
nself build is running properly now! (I checked on Ubuntu too. It looks like on Rocky Liinux is fixed, on Ubuntu not). Nself start is not showing which containers is starting. If I use nself --wizard, no containers are starting. If it's default nself init they are starting in background but nself status is showing that they aren't running: [arek@localhost rail]$ nself status ╔══════════════════════════════════════════════════════════╗ → Services (0/7 running) ○ postgres ✓ Healthy ✗ Unhealthy ● Running ⟳ Starting ○ Stopped → Service URLs GraphQL API: https://api.localhost
nself status | nself status --watch | nself logs | nself doctor Docker is showing them running: [arek@localhost rail]$ docker ps Moreover I can't connect to any of service urls except Mail UI |
Beta Was this translation helpful? Give feedback.
-
|
Hey @CorwinRail, Great that build is working! For the other issues: Fixed the status detection issue - just pushed a fix for .env.local support in status/start commands. Could you pull and try: git pull origin main For the service URLs not working (except Mail UI):
Or alternatively, use the recommended domain in your .env.local: Then rebuild and the URLs will work without /etc/hosts changes. For the start command not showing progress - looking into this now. The services are starting (as docker ps shows) but the output isn't displaying correctly. Let me know if the status fix works and if changing BASE_DOMAIN helps with the URLs! |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately no success. [arek@localhost etc]$ more hosts ╔══════════════════════════════════════════════════════════╗ → Services (0/8 running) ○ postgres ✓ Healthy ✗ Unhealthy ● Running ⟳ Starting ○ Stopped → Service URLs GraphQL API: https://api.local.nself.org
nself status | nself status --watch | nself logs | nself doctor When connecting on browser I recvieve following error: Secure Connection Failed An error occurred during a connection to api.local.nself.org. PR_END_OF_FILE_ERROR Error code: PR_END_OF_FILE_ERROR admin dashboard keep restarting all time: [arek@localhost rail]$ docker ps nself logs is showing following error for that container: 2025-09-17 18:22:55 [admin ] | 2025-09-17T16:18:47.826286569Z exec /usr/local/bin/docker-entrypoint.sh: exec format error |
Beta Was this translation helpful? Give feedback.
-
|
For additional reference. I run example from nhost and there everything run from first time. |
Beta Was this translation helpful? Give feedback.
-
|
The nself cli is a completely independent project from the Nhost cli. They are not meant to use for anything outside of their paid cloud service at all and only marginally refer to being able to run self-hosted but everything is on the user. This project had to be built from the ground up with nothing borrowed or extended from them to make that self-hosted stack work. We even are building our very own Admin as their "Dashboard" only works for the paid cloud product exclusively. Essentially the only thing we do use is nhost-auth which is just a slightly modified hasura-auth service that is already open source by that team. Because of this being a new project from scratch we have a roadmap we're iterating through with the goal of 0.4 and 0.5 being significant steps in being a fully reliable prod-worthy release. But as said in the README the cli is a wrapper and the underlying tech (Postgres, etc) are fully ready for prod and any experienced dev can use us just for the initial help. Though our goal very soon is to be 100% ready -- and threads, bugs, etc. reported just like this thread here as IMMENSELY helpful and we love and appreciate it. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Check out our latest release, v0.4.0 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Latest version 0.3.9 is unable to run. It looks like nself build doesn't create docker-compose.yml and SSL certificates not created.
Tested on MacOS, Rocky Linux, Ubuntu. No success anywhere.
Beta Was this translation helpful? Give feedback.
All reactions