B
Blueprint•11mo ago
Suggestied

Advice Needed for Hosting Blueprint + Pterodactyl Panel in Docker + Git Version Management

Hey everyone! 👋 I’m trying to host the Blueprint panel on Coolify. I’ve already managed to deploy Pterodactyl’s Docker Compose setup successfully, but now I want to switch to Blueprint. Ideally, I’d like to: - Use a Git repository to manage everything (e.g., extensions, configs, Docker Compose file). - Have separate development and production setups, so I can test changes easily. (I have experience with CI/CD) - Make the setup portable, so I can deploy it on other Docker Compose hosting platforms (eg. Coolify self hosted rn) if needed. I’m not entirely sure how to approach this yet, so any advice would be greatly appreciated. Thanks in advance! 🙌
7 Replies
Loki
Loki•11mo ago
Do you have any more specific questions? You already listed everything you have left to do; I don't see where I can improve. My setup is just a compose stack and automated backups for any persistent and regularly changing data. mariadb-dump for the database, Restic for the app volume.
Suggestied
SuggestiedOP•11mo ago
Do you use git? For version management, for adding new extensions etc.?
Loki
Loki•11mo ago
Not for deployment, no. There's already an extensions folder. If I needed to sync between two machines I'd just sync them, why go through a third party? I don't see what version management would help with when it comes to the extensions.
Suggestied
SuggestiedOP•11mo ago
Got it, I understand your point about syncing directly, but I like having CI/CD for deployments. It’s not just about syncing—it's more about automating the process and keeping track of changes over time. Especially once i start working on custom extensions For example: - With Git, I could have development and production branches, test new extensions/configs in development, and deploy stable versions to production. - CI/CD could automatically deploy changes when I push to specific branches, making the process smoother and repeatable. Do you think there’s any downside to setting it up this way for the panel? Or is it overkill for something like extensions?
Loki
Loki•11mo ago
For my use case, it would be overkill. If there's something about your specific use case that this makes easier, I say go for it.
Suggestied
SuggestiedOP•11mo ago
I just really like a git-workflow with ci/cd 😅 So i can easily redeploy it to any server so if i want to move to a different machine i just have to add the .env and it's up and running Do you think it could be possible to have extensions folder git? I'm not that familiar with blueprint yet I'm looking to achieve a git repo that will look like this
│
├── /extensions
│ ├── example1.blueprint
│ ├── example2.blueprint
│
├── /scripts
│ ├── backup.sh
│ ├── deploy.sh
│
├── docker-compose.yml
├── .env.example
├── .gitignore
│
├── /extensions
│ ├── example1.blueprint
│ ├── example2.blueprint
│
├── /scripts
│ ├── backup.sh
│ ├── deploy.sh
│
├── docker-compose.yml
├── .env.example
├── .gitignore
So if i want to add extensions i just drag it into the extensions folder, commit it to deployment branch and its live Althought that would limit me too only use (custom) blueprint addons
Loki
Loki•11mo ago
I don't see why it would limit you to custom extensions only; you'd just have to use a private repository so you're not redistributing extensions. I've noticed an issue when uploading directly to the extensions folder; I'm not sure if it's inotify or rsync or the way they're set up, but occasionally extensions don't sync correctly, then have to be moved out and back into the extensions folder. When you automate it, I'd sync to somewhere else, add a check to make sure the file size has stopped changing for 2 seconds, then move them into the extensions folder.

Did you find this page helpful?