Deploying TwentyCRM on AKS with Kubernetes Manifests
Hello,
I am trying to deploy TwentyCRM on AKS using Kubernetes manifests but have encountered several issues along the way. I followed the instructions provided in the official repository (https://github.com/twentyhq/twenty/tree/main/packages/twenty-docker/k8s) but still haven't managed to get the CRM running successfully.
Here are some of the adjustments I had to make:
Change the path to /k8s/manifests instead of /k8s as mentioned in the documentation.
Remove volumeName from all PVC definitions to avoid errors.
Modify all deployments to set env.value for name: PORT from an integer to a string.
Handle permissions for PostgreSQL by adding an initContainer in deployment-server.yaml to manage permissions on mounted volumes.
Other minor fixes in configurations to align with my AKS environment.
At this point, I have all the resources deployed and running, but the front-end still shows an error:
Unable to Reach Back-end: Response not successful: Received status code 404.
Has anyone managed to deploy TwentyCRM smoothly to AKS and get it running end-to-end? If so, could you share any insights or additional steps that helped and resolved similar issues?
Thanks in advance!
GitHub
twenty/packages/twenty-docker/k8s at main · twentyhq/twenty
Building a modern alternative to Salesforce, powered by the community. - twentyhq/twenty
14 Replies
Question, did you configure the env variables?
https://twenty.com/developers/section/self-hosting/self-hosting-var
I have only changed SERVER_URL and FRONT_BASE_URL IN deployment-server and deployment-worker to match my ingress host from my Azure DNS zone
I had the same issue and had to add:
PG_DATABASE_HOST=db:5432
REDIS_URL=redis://redis:6379
PG_DATABASE_URL=postgres://admin:password@localhost:5432/default?connection_limit=1
REACT_APP_SERVER_BASE_URL=http://localhost:3000
FRONT_DOMAIN=localhost
DEFAULT_SUBDOMAIN=app
SERVER_URL=localhost:3000
FRONT_PROTOCOL=http
FRONT_PORT=3001
PORT=3000
and the other env variables of course.
so you added variables that are missing form official documentatiin to deployment yamls. For exmple PG_DATABASE_HOST to deployment-db.yaml under env, REACT_APP_SERVER_BASE_URL to deployment-server.yaml etc..?
added to .env.
Hi @sven, sorry not bringing a direct solution to your issues, but just curious about the reason behind choosing k8s? Do you have any current needs for large scale running of twentyCRM? or are you just trying it out?
Using it for company to manage internal processes.
Thanks for your answer, I just saw in the general channel that you actually managed to deploy in on AKS as you were initially planning, that's great!!
In case you don't have direct need for k8s and just want to deploy other instances of twentyCRM (or any other app) on a VPS, you could give a try to deploy it with DollarDeploy? We're trying to get user feedback and see if that helps the open-source communities to deploy faster and in a more cost-effective way their instances of open-source apps.
So far we are continuing with k8s, if anything changes will let you know. Good luck
Thanks 🙂 same to you !
@sven I have a discussion on github about potentially creating a HELM chart because the manifests provided leave a lot to be desired. I had to significantly alter them, provide separate secrets, and a separate approach for config maps. I've got it working in EKS (AWS) and GKS (Google) currently, but really need to solidify some things before starting a helm chart
GitHub
Helm chart for Kubernetes · twentyhq twenty · Discussion #8900
Summary The manifests were a good starting point, but there's a lot of variances that need to be accommodated for: NGINX as an ingress controller won't be everyone's preferred. Most peo...
@shairozan just to keep you in loop we managed to modify all manifests to have clean install on azure aks. My intention is to post them all in here for everyone. It would be awesome if you could engage me and my coworker as contributors on helm chart
I'll take a look at them. Need to see what considerations were made for cloud integrations and whether they were done at the NGINX ingress or the native ingress. Most people I've worked with prefer not using the NGINX ingress controller because it's another dependency, and all major cloud providers already have integrations available via annotation for the native network ingress controller. Major being the case. Digital ocean's is a lot different, but AWS, Azure, GKS all have native annotation support for DNS, Load Balancer setup, and SSL termination
But I'd like the helm chart to offer the user the option to use either or. It just needs to handle the helm provisioning of the NGINX controllers