\r\n {{ $t('management.cloneDescription') }}\r\n
\r\n\r\n {{ $t('management.deploymentDescription') }}\r\n
\r\n\r\n {{ $t('pricingForOneTimePaymentsArea.payOnce') }}
\r\n{{ $t(`why.items.${item.id}.subtitle`) }}
\r\n\r\n {{ date_text }}\r\n
\r\n\r\n {{ date_text }}\r\n
\r\n\r\n SaaSConstruct is a codebase (template) for the AWS cloud, consisting of cloud infrastructure, frontend, and backend.\r\n SaaSConstruct can be deployed to AWS to create a SaaS website with payments, authorization, custom AI chatbot, and many more features\r\n (check the demo to see the live SaaS version). It is a great way to get your idea off the ground quickly, save on development costs, and learn about AWS.\r\n
\r\n\r\n The current architecture is serverless, meaning that cloud resources scale down to zero when not in use.\r\n
\r\nThe architecture can be easily changed or extended by simply modifying the infrastructure code (e.g., if you prefer to use other cloud resources, including non-serverless ones).
\r\n\r\nCloud resources used in SaaSConstruct are mostly covered by the AWS Free Tier. For example, the costs of running this website you are currently on and everything behind it are almost zero, even with hundreds of unique visitors daily.
\r\nFor an architecture overview and the AWS services used, see this blog post
\r\n\n In this section, we will set up development and production AWS accounts and place them in AWS organisations so you can access them easily.\n
\n\n An AWS account represents your environment. Each account is\n isolated from other accounts (i.e. cloud resources in one account are independent of resources in another\n account) to ensure security and separation of concerns.\n\n
\n\n AWS Organisations is a group of AWS accounts. It allows you to have\n one place (AWS access portal) to access all the accounts you specify.\n
\n\n If you already have an AWS account, you can skip this step.\n
\nPlease follow an official tutorial from AWS on creating an account: Create an AWS account.
\n\n When you create an AWS account, you create a root user. The root user has full access to the AWS account and should not be used.\n When we set up the AWS organisation later in this tutorial, you will no longer need the root user for access as we will be creating a separate user to access the accounts.\n
\nFor now, protect your account (root user) by doing at least these 2 things:
\nYou can also follow other best practices here.
\n\nGreat, now let's create an AWS organisation.
\nAWS Organisation is a group of AWS accounts. It allows you to have\n one place (AWS access portal) to access all the accounts you specify.
\n\n We will need development and production AWS accounts.\n We will add them through AWS Organisation.\n
\n\nBefore we go any further, we need to decide in which region we will create cloud resources.
\nThis is where you decide which region you will create your resources in.
\n\n If you prefer to choose a different region, make sure the services are available.
\n You can use this AWS\n documentation to check.
\n Check the following services: Bedrock, Amplify, Cloudfront, Secret Manager, Api Gateway, Lambda,\n Cognito, SES, DynamoDb, S3, CloudWatch, CodePipeline.\n
Permission sets allow users to access AWS accounts.
\nGreat, you've created a set of permissions that we'll use to access the accounts.
\n\nNow we will create a group and add a user to it. We will use this user to access the AWS accounts.
\n\n You've just created a user. This user will be used to access both the dev and prod AWS accounts. We just need to add this user to these accounts.\n
\nNow all we need to do is add the user to the dev and prod accounts.
\nCongratulations, let's check your access now!
\n\nNow you can access your dev and prod AWS accounts from one place. Congratulations!
\nWhat we've done so far:
\nNow let's install the necessary tools.
\n\n To continue, we need to set up some tools for your local machine.\n
\n
Please install the following tools:
\nGreat! Let's start with the deployment!
\n\n\n In this section, we will deploy both frontend and backend of our application on AWS, as well as configure the CI/CD pipeline so that deployments are done on git commands. After that, you will have a working website with authentication.\n
\n\n After purchasing SaasConstruct, you will receive an invitation to the GitHub repository.
\n Go to the SaasConstruct repository and clone it (with the main branch only). Make sure you also remove the initial origin (see commands below).\n
\n Got to your GitHub account and create a private repository:\n
\n\n\n Push your local repository into your newly created GitHub repository:\n
\nThis way you can get the latest changes from the original repository.
\nEach time you need to merge changes from the original SaaSConstruct repository into your personal repository, you can do the following:
\nGreat! Let's move on to the next step.
\n\n\nThe codebase consists of 4 folders, each folder is responsible for a part of the functionality of the whole application.
\n\n We will use AWS Amplify Hosting to deploy and host the website (the frontend).\n
\n\nGreat! You have a website. Now let's do the same for the production account.\n
\n\nThe process is essentially the same. Go to your prod account and repeat the steps.
In this case you need to choose the 'main' branch when you create an application, and you don't want to password protect the site as it will be open to the world for people to visit.
Congratulations, you now have development and production set up for your frontend. Your frontend will be built and deployed to the appropriate AWS account whenever you 'git push to the dev or main branch.
\n\nYou can easily set up a domain for your website.
\nCongratulations! You now have a website that is accessible through a domain. You can visit the domain and the website will be displayed in the browser.
\n\nAn alternative to GitHub Actions is AWS CodePipeline, a CI/CD solution from AWS. Follow these steps to set it up (or skip this section if you chose
First, go to your GitHub repository settings and disable GitHub Actions. Click \"Disable actions\" and then \"Save\".
\nNow, we need to create a connection between your AWS account and your GitHub repository.
\nGreat! Let's move on to the next step.
\n\nNow we need to configure the global-dev-config.ts file, which you'll find in the 'cdk/global-config' folder.\n
This file represents the application configuration for your development environment that does not contain sensitive data (sensitive data is handled by AWS Secret Manager).\n
For the dev account, change only these fields:\n
You can get the amplifyId by going to AWS Amplify and selecting your app.
\nSimilarly, we set up the prod account (global-prod-config.ts file). Change only the fields below . The difference is that you need to write to the domain that we configured when we
Let's push to the repo to update your configs:
\nGreat! Now let's configure AWS Secret Manager.
\n\nAWS Secret Manager is used to store sensitive data such as emails, API keys, etc.
\n We need to store some information so that AWS CodePipeline can use it when creating cloud resources.
\n We need to do this for both dev and prod accounts.\n
Let's start with the dev account:
\n\n Now we will deploy the AWS CodePipeline. We will not deploy the whole backend for now, as we set firstDeploy=True in global-dev-config.ts and global-prod-config.ts.
\n
First, we will deploy to the dev account, and then repeat the same steps for the prod account.
\nNote: You have set up temporary credentials for the dev account. To check if this worked, you can run any AWS CLI command that returns the account id. Example:
\nGreat, now let's do this again for prod account
\nThe steps for the prod account are the same as for the dev account.
\nCongratulations! You can now see the CodePipeline in both your AWS accounts (dev and prod).\n
\nLet's deploy the backend.
\n\nNow all we need to do is set one value and push it to your GitHub repository.
\n\nAlternatively, you can go to AWS Amplify (for both dev and prod) and simply click: Redeploy this version.
\nCongratulations!
\n\nYou are now ready to use the website (both dev and prod versions):
\nGitHub Actions is a CI/CD solution from GitHub. GitHub Actions is a CI/CD solution from GitHub. When you push changes to your repository, it automatically updates your services. It is very popular and highly recommended. Follow these steps to set it up:
\n\nNow we need to configure the global-dev-config.ts file, which you'll find in the 'cdk/global-config' folder.\n
This file represents the application configuration for your development environment that does not contain sensitive data (sensitive data is handled by AWS Secret Manager).\n
For the dev account, change only these fields:\n
You can get the amplifyId by going to AWS Amplify and selecting your app.
\nSimilarly, we set up the prod account (global-prod-config.ts file). Change only the fields below . The difference is that you need to write to the domain that we configured when we
Let's push to the repo to update your configs:
\nAWS Secret Manager is used to store sensitive data such as emails, API keys, etc.
\n We need to store some information so that GitHub Actions can use it when creating cloud resources.
\n We need to do this for both dev and prod accounts.\n
Let's start with the dev account:
\n\n We need to connect your GitHub repository and your AWS accounts so that GitHub Actions can provision resources in AWS. We will create a Trust Stack which will create AWS roles for your GitHub repository.
\n
First, we will deploy to the dev account, and then repeat the same steps for the prod account.
\nNote: You have set up temporary credentials for the dev account. To check if this worked, you can run any AWS CLI command that returns the account id. Example:
\nGreat, now let's do this again for prod account
\nThe steps for the prod account are the same as for the dev account.
\nCongratulations! You can now see these stacks in Cloudformation in your dev and prod AWS accounts.\n
Example:\n
Now let's set up GitHub Actions and deploy the backend.
\n\nNow all we need to do is to push the code to your GitHub repository.
\n\nAlternatively, you can go to AWS Amplify (for both dev and prod) and simply click: Redeploy this version.
\nCongratulations!.
\n\nYou are now ready to use the website (both dev and prod versions):
\nIf you have any problems deploying the backend resources and CI/CD for them, you can inspect the resources.
\nAfter deleting the stacks, make sure you also manually delete the following resources (just go to the corresponding service in your dev or prod accounts):
\nUsually you won't need to, but you can always review deployments of your frontend in AWS Amplify Hosting and access the logs to see what went wrong.
\n\n In this section, we will add social sign-in flows, such as one from Google, so that users can signup/signin in to the website using their Google account.\n
\nHere are the steps to enable Google Sign-In for your website.
\n\nCongratulations! Now users can use Google Sign-in on your website.
\n\n In this section, we will add payments, either Stripe or LemonSqueezy. Stripe is popular with large companies and LemonSqueezy (which is Merchant of Record) is popular with small teams because it handles sales tax/VAT.\n
\n
\n For these payment systems, SaaSConstruct supports both Checkout (initial payment) and Customer Portal (subscription management), which means that users can buy your products and manage their subscriptions (change, cancel, renew) as well as their billing information and invoices without you doing anything.\n
LemonSqueezy is a payment service (payment gateway) that allows you to accept payments from your users.
The main advantage is that it is a Merchant of Record, meaning it handles VAT/sales tax.
\n It's very popular with small businesses that don't have a large team of accountants on their side.\n
LemonSqueezy was acquired by Stripe, but it is not the same payment service.\n
First, we will create products in a test mode that allows you to test payments. This only applies to your AWS dev account.
\nStore id:
\nNote: make sure you copy it correctly (for example, your Standard Monthly plan variant id will be LemonSqueezyPlan price id with the name StandardMonthly).
\nThe LemonSqueezy Customer Portal allows your users to manage their subscriptions, including upgrades, downgrades and cancellations.
\nGo to AWS Secret Manager (dev account) and update your secrets. Add the following:
\nAlternatively, you can go to AWS Amplify (for dev account) and simply click: Redeploy this version.
\nCongratulations! You now have a payment system integrated into your website.
\n\nStripe is a payment service (payment gateway) that allows you to accept payments from your users.
It has a lot of features.
\n It is very popular with all kinds of businesses.\n
First, we will create products in a test mode that allows you to test payments. This only applies to your AWS dev account.\n
\nNote: make sure you copy it correctly (for example, your Standard Monthly plan price id will be StripePlan price id with the name StandardMonthly).
\nThe Stripe Customer Portal allows your users to manage their subscriptions, including upgrades, downgrades and cancellations.
\nGo to AWS Secret Manager (dev account) and update your secrets (you have noted them in the previous steps). Add the following:
\nAlternatively, you can go to AWS Amplify (for dev account) and simply click: Redeploy this version.
\nCongratulations! You now have a payment system integrated into your website.
\n\n\n\n\n\n In this section we will add a RAG (Retrieval-Augmented Generation) system. This is a chatbot that is trained\n on your data to answer questions that visitors to your website may have.\n
\nAWS Bedrock is an AWS service that gives you access to a variety of LLMs (large language models) that can generate text data. If you send a request to LLM asking for help with general tasks (such as writing an email or answering common questions), they will usually be able to help.
\n But these models don't have any knowledge about your custom data (e.g. about your SaaS, what it can do, etc.). So we need to store the data and then use it when we make a request to LLMs. Your custom data is stored in a vector database.\n
\n Pinecone is a vector database where you can store your custom data (information about your SaaS), so when the user asks your chatbot a question, the backend of your SaaS will find relevant parts of that data that answer the question, and send that data to LLM to construct a final result.\n
\n\nIf this sounds confusing, do not worry, SaaSConstruct does all this behind the scenes, you only need to do an initial configuration.
\n\nNow we need to configure the global-dev-config.ts file and global-prod-config.ts file, which you'll find in the 'cdk/global-config' folder.\n
Change only this field:\n
\n OpenAI Assistant is an OpenAI service that gives you access to a variety of LLMs (large language models) that can generate text data. If you send a request to an LLM asking for help with general tasks (such as writing an email or answering common questions), it will usually be able to help.
\n However, these models don't have any knowledge about your custom data (e.g., details about your SaaS, its capabilities, etc.). To address this, we need to store relevant data and use it when making requests to LLMs. Your custom data is stored in a vector database.\n
\n OpenAI Assistant includes a serverless vector database where you can store your custom data (such as information about your SaaS). When a user asks your chatbot a question, the backend of your SaaS retrieves the most relevant parts of that data and sends them to the LLM to generate a final response.\n
\n\n\nIf this sounds confusing, do not worry, SaaSConstruct does all this behind the scenes, you only need to do an initial configuration.
\n\nNow we need to configure the global-dev-config.ts file and global-prod-config.ts file, which you'll find in the 'cdk/global-config' folder.\n
Change only this field:\n
Go to AWS Secret Manager (dev and prod accounts) and update your secrets. Add the following:
\n\n In this section we will be increasing AWS quotas. We will send requests to AWS explaining why we need such an increase.\n
\n\n\nAWS SES is an email service from AWS that can send both transactional (such as sending an email to confirm account creation) and marketing emails.\n
\n\n\n When you create an AWS account, you can only use AWS SES to send emails to verified identities (such as the test user we created).
\n This is because your AWS SES service is in a sandbox. We need to ask AWS to give us production access to the production AWS account.
\n
\n Please refer to the official documentation on how to request production access and follow the advice below.\n
\n\n In this section we will go over the development flow and how you can develop your SaaS beyond the SaaSConstruct template.\n
\n\nLocal development allows you to develop the frontend locally and connect it to your backend in your AWS development account.
\n\n\n\r\n {{ item.date_text_1 }}\r\n
\r\n