Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.

Building the AMI

Make the pre-instance to make the ami

EC2 Dashboard
ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-20210430 - ami-00399ec92321828f5 (Since 2021-08-21)

    Old: ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-20210223 - ami-08962a4068733a2b6 (Since 2021-03-21)
    Older: Ubuntu Server 18.04 LTS (HVM), SSD Volume Type - ami-05c1fa8df71875112 (Since 2019-08-11)

don't put user data in for the pre-process
user the default VPC security group so you can test port 80

Once your EC2 Instance is up and running, log in and run the following sequence:

ssh ubuntu@
sudo bash
pwd    # /home/ubuntu
git clone
cd ami-sql
# Navigate to make sure you see the empty Apache screen...
systemctl poweroff

Make an AMI by taking a snapshot of your EC2 instance once it is powered off and has stopped.


If you are not making an official release AMI, please don't start it with "tsugi-". official releases look like:


You will get an instance id like ami-081eb8abf28330636 - if it is an official release make sure to set it to public after it is created.

Non AMI Builds

This process is specifically to build a reusable AMI that can be used to quckly deploy Tsugi servers from an AMI. There is a more flexible build process that is more generic (i.e. build docker containers or just run the software on Digital Ocean) documented at

The commands in are similar to the commands in

Creating the Necessary Services and Building the User Data

Take a look at the file - make your own copy of it. Once you edit it do not check it into a public repo.

Make an Aurora instance. As you create the instance, you set up the master user name and password (effectively the MySQL root account). When this is done, you will want to log into an EC2 instance that is in the VPC and run the following commands to create the table and sub-account:

mysql -h -u tsugi_root_account -p
(Enter the master password you created)
GRANT ALL ON apps_db.* TO 'apps_db_user'@'172.%' IDENTIFIED BY 'APPS_PW_8973498';

Now you can set up the user_data for the database in the file. Look at the sample file in this folder - it has commands like:

export TSUGI_USER=apps_db_user
export TSUGI_PDO=";dbname=apps_db"

Make an EFS volume and put its connection information into:


Make a single-node ElasticCache / Memcache server. I use a t2.small and it has plenty of power and memory since PHP sessions in Tsugi are pretty small. Tsugi does not yet like a cluster of memcache servers - so just make one of the correct size. Watch things like free memory on a Cloudwatch dashboard - you will likely find that it is very relaxed. Configure in your as follows:


Setting up Email

We need to enable outbound mail using Amazon's Simple Email Service:

Go into SES - Email addresses and verify the address that mail will come from (i.e. like - this happens quickly.

Go into SES - Domains and setup a new domain. You will need to put a TXT record and some CNAMEs into your DNS tables. It may take up to 72 hours to verify your domain.

Then make an IAM user with this JSON policy:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": "ses:SendRawEmail",
            "Resource": "*"

Record the Access Key ID and secret for that IAM user. You can only view the Secret Access Key at the moment of creation - if you lose it - you must make a new one. Put the Access Key ID and Secret in the SASL_PASSWORD field below separated by a space.

Add these records to the for the servers.

export POSTFIX_RELAYHOST='[]:587'
export POSTFIX_SASL_PASSWORD="[]:587 A...KEY.......34XFVQ:A....SECRET...3b7ihyatSEWH0hqnNGRh1sJOUa1fcn"

I think you can use the same IAM user for more than one domain.

Making an EC2 Instance Using the AMI

To build your EC2 Instance, make a new instance and start with the AMI you created above. Or start with one of the official AMIs (if we make them available).

Put in the user data under Advanced - copy everything from the "#! /bin/bash" to the end of the file. When the EC2 provisioning process sees the hashbang, it runs the user data as a shell script.

To debug the install process, you might find it useful to look at:

After it comes up - you can see the post-ami process output in:

ssh ubuntu@
tail -f /var/log/cloud-init-output.log

Making an Autoscaling Group Using the AMI

It is good for testing to intiially make your Launch Configuration and AutoScaling Group without automatically adding them to your Target Group for your ELB. This way you can get things right and verify by going to the IP address in the web browser and SSHing in to look around before you add it to the Target Group.

First make a Launch Configuration exactly like spinning spinning up an EC2 instance. Then make an autoscaling group that uses that launch configuration. You can't edit a Launch Configuration but you can copy a Launch Config and make a new one to tweak.

A good testing trick as you make and test new launch configurations is to edit the ASG and switch from desired=1, min=1, max=1 and desired=0, min=0, max=0 to bring the instances up and down.


About EFS and /etc/fstab

About Verifying a Domain with SES


A Scalable AMI for Tsugi using SQL for cluster config






No releases published


No packages published