Advice on Deployment Strategy

Hello all, I have a project which is structured like so:

project/
├── handler/
│   ├── src/
│   ├── Dockerfile
│   └── package.json
└── website/
    ├── src/
    ├── Dockerfile
    └── package.json
shared/
├── db/
│   ├── prisma/
│   │   └── schema.prisma
│   ├── src/
│   │   └── index.ts
│   └── package.json     
└── logger/
    ├── src/
    │   └── index.ts
    └── package.json  
package.json
turbo.json
docker-compose.yaml

project/
├── handler/
│   ├── src/
│   ├── Dockerfile
│   └── package.json
└── website/
    ├── src/
    ├── Dockerfile
    └── package.json
shared/
├── db/
│   ├── prisma/
│   │   └── schema.prisma
│   ├── src/
│   │   └── index.ts
│   └── package.json     
└── logger/
    ├── src/
    │   └── index.ts
    └── package.json  
package.json
turbo.json
docker-compose.yaml

The handler is a Discord Bot and the website is a SvelteKit Dashboard. The shared folder contains the database which is using Prisma with MongoDB. I currently have a docker-compose.yaml with 4 services: - Redis - Gateway - Proxy - MongoDB (Node Replica Set) All four of these are required for the handler to run. For context, I'm essentially using the Gateway as a proxy between Discord API and my handler's application logic - redis is used as a Message Broker. A direct MongoDB connection is used by both the handler and webste via Prisma. My questions: - Should I move MongoDB and Redis to a standalone services on Dokploy? - How would I go about deploying the website and handler? - Do I use a Compose Service for the handler and Railpack for the website? Or could I just use Compose for both? - How would this look for production?

7 Replies

Henrik•2mo ago

No two production pipelines look the same, but how overkill do you want to go?

AlexisOP•2mo ago

I really just want to know how to approach this. I’m seeing a lot of mixed information on turborepo deployment. My end goal is to have b data backups, staging, and rollbacks with 0 downtime. In terms of overkill I’m not too sure. The bot only serves a couple thousand servers at the moment so most of my infrastructure is already overkill lol

Henrik•2mo ago

Every application should be abstracted out to it's own application. The production server should not build it, but pull the image from a Docker registry. You can self host that if you want to. The mongo db should be it's own database service to enable Dokploy's automatic backup. The backup should be offsite from the VPS. The registry is not as important, but could also be beneficial to have offsite. The building of your application should be done in a CI/CD pipeline where you then use the Dokploy API to initiate deployments.

AlexisOP•2mo ago

Thanks this is what I figured. Would the gateway and proxy also be their own application? They’re already images on Docker Hub

Henrik•2mo ago

I don't know how they are incorporated into you stack, but really shouldn't need to supply you own proxies, but rather rely on the existing Traefik instance that comes with Dokploy. This depends on how your stack is.

Siumauricio•2mo ago

I prefer to use applications instead of docker compose tbh, you have much more features than in compose, so my recommendation would be better to use applications and the dedicated bd services.

AlexisOP•2mo ago

Yep that’s what I ended up doing. Using docker compose to quickly spin up the environment for local development and then for production I’m using applications for everything

Gaming

Programming

Advice on Deployment Strategy

Did you find this page helpful?