Hello.
I would like to replace my private DNS infrastructure with deSEC stack, but I’m not sure if it’s actually praticable, so I’m here to ask:
Is it possible to run the stack completely independent from desec.io services, in a self-hosted fashion?
Hi kenayagi,
Thanks for your message, and welcome to deSEC! 
Yes, it is possible and also very welcome to run the deSEC stack in a self-hosted fashion. Technically, it should be possible by following the README in our main repository, but the descriptions are probably not very user-friendly. On the the other hand, we’re very glad about your request, and we’d like to improve the installation procedure (ideally have some sort of package at some point that one can install).
Would you like to give it a try? If you prefer, we can also discuss the procedure in a call first. Feel free to send an email if you’d like to go that route.
Stay secure,
Peter
Thanks for your reply Peter.
I’m really happy that self-hosting is endorsed! 
I thank you very much for your availability to get in touch with a call, but I think that trying to explain each other directly on this board could also be useful to somebody else in the future. 
Briefly, I tried to follow the instructions on the README, but I cannot get the stack to start.
- Locally clone the repo
- Copy .env.default to .env and customize settings
- Run ./dev script
But after that I crash on some errors and several containers keep restarting (www_monitor, www, webapp, openvpn-server).
The main error apparently is:
nginx: [emerg] host not found in upstream "webapp" in /etc/nginx/sites-available/90-desec.static.content:12
What am I missing?
I also advance a suggestion: publishing the official tagged images directly on a Docker registry could improve final user experience, since in that case a single docker-compose.yml file could be enough to describe the entire stack.
But I also admit that keeping the full source code directly on host is paranoidly relieving! 
Cheers,
K
Hi kenayagi,
please see if the directory webapp/node_modules exist and is populated. If it is not, you could either run npm install on your host in the webapp/ directory (i.e., not inside any container), or see if this commit could help you out.
Let us know how it goes!
Best,
Nils
I tried to manually run the webapp command (since with the default syslog driver I couldn’t get any output from the container stdout).
It seems that npm cannot install all dependencies:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: webapp@0.1.0
npm ERR! Found: vue@2.6.12
npm ERR! node_modules/vue
npm ERR! vue@"~2.6.12" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer vue@"3.0.5" from @vue/compiler-sfc@3.0.5
npm ERR! node_modules/@vue/compiler-sfc
npm ERR! peerOptional @vue/compiler-sfc@"^3.0.0-beta.14" from @vue/cli-service@4.5.11
npm ERR! node_modules/@vue/cli-service
npm ERR! dev @vue/cli-service@"^4.5.8" from the root project
npm ERR! 1 more (@vue/cli-plugin-babel)
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.I tried to install the node dependencies on my machine using node v14.15.5 and npm 6.14.11 and npm install in the webapp directory (no container), and did not see any dependency conflicts. Which version of node and npm are you using? Which command exactly did you use?
Why are you suggesting to run npm on the host?
One of the coolest features of Docker is exactly the containerization of all the application’ ecosystem.
So I’m largely against using the software installed on the host, instead of what’s available inside the container.
I ran npm inside the webapp container, where Node.js has version v15.8.0 and npm is on version 7.5.1.
The command run (on a fresh volume) is simply npm install, that lead me to previous error. 
I can reproduce the problem when using npm install inside the container. As far as I can tell, this problem only occurs when using a newer version of npm (for me, the one inside the contianer) and when there is no package-lock.json file present, which is why this hasn’t surfaced so far.
I’m not sure how to fix it yet, but I attach my package-lock.json file that you can place in the webapp directory to the run npm install inside the container, which works fine on my system.
Needs to be unpacked: package-lock.json.gz (289.9 KB)
We’re tracking this bug at webapp's npm install fails · Issue #517 · desec-io/desec-stack · GitHub
Hi kenayagi,
We did that so it’s easier to do real-time development with live updates in the browser. A more dockerized setup probably is also possible, but we didn’t spend the time sorting out the required volumes etc. We’d certainly accept a PR to improve this!
Stay secure,
Peter