Self-host docker #265
Comments
|
The self-host doc is quite new and it reflects our own self-host process. We do understand that a docker compose file is easier for most people, we are going to create one soon |
|
I currently have a fork with working Docker builds and a single-command docker-compose based build/startup process. I've been using it for several weeks at this point to iron out issues and simplify the setup. I also built a Helm chart for Kubernetes deployments that I'm already using with our deployed services. I'll be opening a PR here for the Docker stuff tomorrow and will write up docs for the Helm/Kubernetes deploys as soon as I'm done putting a few production quality example configs together (to make it easier for those that are less familiar with Kubernetes). Assuming my Docker PR gets merged, the Docker Compose build/deployment process will be as simple as... docker compose build
docker compose up -dKubernetes will definitely be a bit more involved than that, but I think everyone probably already knows that about Kubernetes. ;) |
That is awesome! I just got started with it but since you already have something working, I will just wait for your PR then! |
|
root@stack-auth:~/stack/apps/dashboard# pnpm run dev
▲ Next.js 14.2.3
✓ Starting... api: |
|
@csyedbilal You need to run that command from the root of the repo, not the dashboard directory. Follow the docs closely. Every command is always from the root directory. |
|
@jshimko please check dash: http://5.9.178.126:8101/ it is just loading up again again. and follow this but same |
@csyedbilal Your URL'S need to start with https when using production builds. You can't use unencrypted connections to send auth cookies. You will need to use actual domain names instead of IP's and then set up SSL certs for them. I do think the dashboard should probably have better error handling for that situation though. It's definitely not obvious what the issue is when you have an infinite loop of refreshes that keeps clearing the browser console before you can read anything. |
|
@csyedbilal a temporary workaround for the https thing when using the Docker builds from my PR is you can set NEXT_PUBLIC_INSECURE_COOKIE=true on the dashboard container. That should allow you to use the dashboard without SSL certs. That is VERY unsafe for production though, so definitely do not use that for anything other than testing. |
|
@jshimko git clone --single-branch -b docker-builds https://github.com/jshimko/stack.git stack-docker I’ve set up an NGINX proxy with SSL on the following domains: https://api.huctech.me/
Steps Taken I followed the instructions regarding rebuilds, i.e., if code is changed, I explicitly ran: Request Thanks in advance for your help! |
|
@csyedbilal I assume it's a configuration issue because I have those same Docker builds deployed with no issues. Make sure you have set all of your environment variables for URL's, API keys, etc. Just leaving everything like it is on my branch is NOT adequate or secure. You need to configure things for your own deployments. You also don't do that by setting new values in the Dockerfile and building again (which it appears you did above). You set them at runtime using whatever tool is running your containers. If that's Docker Compose, you either set values in the compose config file or the .env.docker file it currently loads. I feel like I should also mention that if you're not comfortable with configuring and debugging Docker builds in production, you may want to consider Stack's hosted service. Especially because this is user authentication and security is very important in this context. Just something to consider. For example, since I can see that you have just used the default docker-compose config that is intended for local development and testing Docker builds, I now have enough information to access your database (and I just did). I can also be reasonably sure you used default secret values as well, so that also means I have full access to your Stack API (also just confirmed by listing API keys in your database).
So yeah, I would definitely make sure you know what you're doing before self hosting something like a user auth service. Step 1 - don't expose the Postgres container port publicly EVER. Step 2 - don't use usernames, passwords, secrets, etc. from a public open source repo. Always configure everything yourself or else anyone with access to the repo will know your secrets. |
|
@csyedbilal I just pushed a commit to remove the exposed database ports so that nobody else misses that if they try to use this docker-compose config in production. But my original comments still stand. This docker-compose config is just meant to be a working reference for spinning everything up in Docker containers. It's not a production config. You should only be using that as a starting point for your own deployment config. You will always need to set your own environment variables and ensure your server doesn't expose anything that it shouldn't. For example, you probably shouldn't have anything other than nginx and port 443 exposed on that server (meaning this shouldn't be possible: http://api.huctech.me:8102). One more item... the Svix JWT secret in Anyway, I just wanted to make sure to point out a few of the ways that self-hosting can come with a lot of security responsibilities so that you and others interested in self-hosting understand some of the ways your security can be easily compromised if you're not familiar with all of the configuration. Be careful out there! :) |
|
@jshimko it is worked thanks! but i did git pull to move production. stack-backend | All migrations have been successfully applied. thanks again for security recommendations! |
Getting errors after errors. Why is there no docker support?
The text was updated successfully, but these errors were encountered: