This tutorial shows how to deploy an application with an SQL database to AWS Beanstalk. It assumes that you already have an AWS account and have access to your console.
SQLite databases are not supported by AWS Beanstalk. You have to use a different one such as Postgres, MySQL, MariaDB, Oracle or MSSQL.
Make sure that the SQLite driver is also uninstalled.
ormconfig.json) file with this one:
And complete your configuration file
config/default.yml) with your local database credentials:
The below credentials are an example. If you want to use them, you need to install PostgreSQL on your local host, create a database named
my-dband install the postgres driver in your project (
npm install pg). But you are free to use another database with other credentials if you want to.
If you do not use sessions, then remove the store import and the store option from the
createApp function in the
If your application uses sessions, you need to provide a session store.
Here is an example with connect-redis:
This guide does not explain how to set up a redis database on AWS Beanstalk.
Go to https://console.aws.amazon.com/elasticbeanstalk/home and click on Get Started.
Enter the name of your application, choose the Node.js platform and select the Sample Application.
AWS creates and loads the new application. This takes a few minutes. Then check that the application health is ok and open the application.
If the health is incorrect, click on the Causes button to see what happened.
The home page should look like this:
Now it is time to configure your environment and add a database. Click on the Configuration button and set the environment variables
NODE_ENVvariable tells FoalTS to look at the production configuration (for example
DATABASE_SYNCHRONIZEvariable tells TypeORM not to update the database schema on every application launch (see section Generate & Run the Database Migrations below).
Then create a new database from the configuration page.
Choose the database engine (postgres in this example) and enter the production database credentials.
Build the app.
Create an archive from the directories and files
Upload the archive to AWS.
The application restarts. This may take a few minutes.
Warning, warning: this section is only compatible with projects created with FoalTS v0.8. If you need a tutorial for v1 and above, feel free to open a Github issue for that.
Migrations are SQL queries that modify the database schemas (definition of the tables, relations, etc). By default, every new Foal project is created with the option
synchronize: true in its
ormconfig. This setting updates the database schema on every launch of the application.
But using this in production is considered unsafe (data could be lost for example if a model is changed by mistake). That's why we will generate and run migrations manually. To do this, we will need access to the database.
Warning This section assumes that you have previously set the environment variable
false. This overrides the
synchronizesetting on AWS.
Go to AWS database page and click on your database.
Save the URL endpoint and click on the VPC security group. We will tell AWS that we can access the database from our local host.
Add a new inbound rule. Make sure you don't delete the one that already exists.
You are now able to communicate from your local host with the production database (as long as you provide the correct credentials).
The next part of the tutorial assumes that you did not change the default option
synchronize: truein the
ormconfigfile. This is probably the case if you have never had to deal with migrations before.
Open a new terminal/console.
Enter the database credentials.
On Mac and Linux
Generate the migration.
A new migration file appears in
src/migrations/. Check that it is correct and then build it.
Then run the migration.
The database schema is updated. Your remote application should now run properly.
Close your terminal / console. Do not start your local application in the same terminal, otherwise it will run on your production database.
Caution: Running migrations is always sensitive part of deployments. You should always back up your data before doing such a thing.