Deploying TwentyCRM on AKS with Kubernetes Manifests

[plain sundial]

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!

[wild sonnet]

Question, did you configure the env variables?
https://twenty.com/developers/section/self-hosting/self-hosting-var

[plain sundial]

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

[wild sonnet]

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.

[plain sundial]

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..?

[wild sonnet]

added to .env.

[olive tapir]

Hi @plain sundial, 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?

[plain sundial]

Using it for company to manage internal processes.

[olive tapir]

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.

[plain sundial]

So far we are continuing with k8s, if anything changes will let you know. Good luck

[olive tapir]

Thanks 🙂 same to you !

[quartz stone]

@plain sundial 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

https://github.com/twentyhq/twenty/discussions/8900

[plain sundial]

@quartz stone 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

[quartz stone]

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