I cannot provide guidance for all environments, because even in Azure you have multiple opportunities:
As a general guidance I would say the following:
1. How it is deployed?
Squidex is cross-platform and can be run on all major operation systems. It comes with 3 different deployments artifacts:
- Source Code: If you need to build it yourself.
- Binaries: If you have a Linux server or Windows server with IIS or another environments where Docker is not an option.
- Docker images. If you have an environment with docker support such as Docker. Docker-Compose, Swarm or Kubernetes or if you start with a new server from scratch.
2. Where to deploy Squidex?
This is usually defined what you are used with and what you have already in place? If all your other systems are running on Azure: Go for it. But personally I think Google Cloud is better and both of them are overpriced for small deployments.
For only 20% of the price you can get a very good setup on vultr. https://vultr.com
3. How to deal with external dependencies?
Squidex has three dependencies that need to be solved:
- Where and how do you setup MongoDB?
- Where do you store assets?
- How do you deal with https?
Again, this depends on the environments and skills. If you need stability and failover you need a replica set with at least 3 nodes (2 normal nodes and an arbiter).
Deploy it yourself
If you have the skillset to deploy MongoDB yourself, it is usually cheaper, but there are a few things to consider:
- Try to install MongoDB on a machine with SSD
- Ensure that your database server is not accessible from the public internet without username and password. It sound stupid but there have been a lot of leaks recently.
- Have a proper isolation between MongoDB and your other services, e.g. with cgroups (Docker) or VMs. It is not as important as the other points but MongoDB tends to consume a lot of Memory over time.
Deploy it with ready to use scripts
If you do not need full control you can use ready to use scripts. For Kubernetes there are helm charts available and the docker-compose file that is provided for Squidex also installs MongoDB.
Use a ready to use solution
If you have the money: Use MongoDB atlas or other managed solutions: It costs more but also provides services like backup, recovery and monitoring.
If you work with assets in Squidex you have to let them store somewhere. Squidex provides several providers:
File system: The fastest, but if you use Docker you need to ensure that you have a volume for your assets, otherwise they might get lost after restart.
Cloud Providers: Azure (Blob Storage), AWS (S3) and GCE are supported. Best and cheapest if you are already using one of these providers.
MongoDB: MongoDB has a solution for files called GridFS. You can store your files in your MongoDB database. Not as fast as the others but works pretty well and makes backup easier as you only have to backup your MongoDB databases.
Squidex needs to run with https. There are so many reasons for that. And again there are several opportunities:
- Use a reverse proxy, e.g. nginx with a custom certificate or lets encrypt. I follow this approach for docker-compose templates.
- Use a Kubernetes ingress.
- Use a CDN provider like Cloudflare.
- Buy a certificate and setup the certificate directly in your installation, e.g. read this: https://docs.microsoft.com/en-US/aspnet/core/security/docker-compose-https?view=aspnetcore-3.1
- Use a service from your cloud provider.