Strapi Serverless
Strapi is an open-source headless CMS built with NodeJS. Using Strapi you can easily design and publish the content consumed by your apps via API. Strapi provides a great admin UI portal where you can design your data models, and create and manage content.
The benefits of using the Strapi Serverless Template on Microtica for your projects are the simplicity of setup and low maintenance while having the infrastructure on your own AWS account. We are following the GitOps and declarative infrastructure approach for stable, more reliable, and predictable deployments.
With this template, Strapi can coexist with your existing AWS infrastructure and you always have the flexibility to extend this setup with additional cloud resources.
Infrastructure ownership
The Strapi infrastructure will be provisioned on your own AWS account.
You retain full control over your infrastructure and data while getting all the benefits of infrastructure automation.
Click Deploy with Microtica below and follow the template steps to deploy your Strapi application on your AWS account.
Since Microtica deploys on your cloud account, you would expect nothing less than complete transparency of what resources are going to be provisioned.
Using the Strapi Serverless template, you will create two components in the environment:
- VPC — VPC, subnets and networking
- Strapi - Container infrastructure based on Fargate, application load balancer, persistent storage, relational databased and S3 storage.
The Strapi Serverless template uses an Amazon EFS file system to store the persistent Strapi files:
- image uploads — media files storage
- api folder — only for the standalone setup where you don’t have your source code connected via Git (default). In this guide, we will explain how you can deploy your existing Strapi project
- data folder — store the sqlite data file, if database client is sqlite (default) The data stored in these folders will persist on subsequent deployments, application restarts or even if you kill the container completely.
The template provisions an RDS database only if the database client is mysql or postgres.
The database is encrypted using a custom KMS key. The database password is automatically generated and stored securely in an AWS Secret Manager secret.
By default, the template provisions an AWS Fargate cluster with one container. For production environments we recommend at least two containers running all the time. This will also ensure a zero-downtime deployment.
The Fargate services are exposed via Application Load Balancer. When using a custom domain, which is recommended for production, the domain certificate will be attached and SSL termination will happen on this load balancer.
Since we use persistent file storage, all containers share the same file system.
The Strapi application logs are stored in CloudWatch Logs. You can monitor the logs from the Fargate console under tasks. The default log retention is 90 days.
These environment variables will be provided in the Strapi application runtime.
Variable | Description |
AWS_BUCKET | The name of the S3 bucket used for storing the media files. |
AWS_REGION | The AWS region in which the infrastructure is deployed. |
DATABASE_CLIENT | Type of the database to be used. Possible values: sqlite, mysql and postgres. |
The following environment variables are provided only when DATABASE_CLIENT is set to mysql or postgres.
Variable | Description |
DATABASE_HOST | Host of the RDS database. |
DATABASE_PORT | Port of the RDS database. |
DATABASE_NAME | The name of the database (default is strapi). |
DATABASE_USERNAME | Database username. |
DATABASE_PASSWORD | Database password. |
DATABASE_SECRET_ARN | ARN of the Secret Manager secret where database connection information is securely stored. This parameter can be used as an alternative to the separate database parameters above. |
The estimated cost of the AWS cloud depends on the configuration of the Strapi infrastructure. Below is the cost estimation breakdown based on different configurations assuming the resources are running all the time:
- sqlite with one app container (0.25 vCPU and 0.5GB memory) the costs is around $30/month
- MySQL with one app container (0.25 vCPU and 0.5GB memory) the cost would be around $45/month
- PostgreSQL with one app container (0.25 vCPU and 0.5GB memory) the cost would be around $55/month
- each additional container with the default config is $14/month
Additional costs apply for using the AWS EFS for storing media files (~$0.09 GB/month).
You can reduce the cost of your non-production Strapi environments with our AWS Cost Optimization feature that is coming soon.
To save costs while using Stapi in a non-production environment, consider running it from Monday to Friday, 8 hours per day. This schedule can help you achieve at least a 65% reduction in your cloud expenses.
In the Resources or Cost Dashboard, create a Saving Schedule to implement these cost-saving measures.