You need a place to store and maintain all the content that makes up your website—HTML, javascript, CSS, images, etc. This is referred to as an “origin”.

The Akamai edge network communicates with your origin server during client requests, grabs all of your website content, and holds it in cache for quick access to future requests. This step of the tutorial shows you how to create compute instances (Linodes) with Akamai Cloud to act as virtual origin servers.

High availability

If you only need one origin server, why do you need multiple Linodes? A high availability architecture made up of multiple compute instances is used to create redundancy and eliminate a single point of failure.

You want your site to be accessible to your clients all the time. By using multiple Linodes, you are creating a highly available setup that combines load balancing and failover functionality. This better protects your site’s uptime against potential scenarios like hardware problems or network overload.

Cloud-based virtual machines also eliminate the overhead that a physical redundant network could create. Akamai Cloud’s cost-per-usage model lets you scale your site as client-access requests increase. Linodes are easy to create and maintain, so you can quickly add another one to your cloud to expand redundancy as needed.

🚧
The Linodes created in this step of the tutorial are not meant for production workloads. They are meant to illustrate the concept of a basic high availability architecture.

1. Store Linode instance details

There are a few identifiers (ids) you need to gather so you can create a Linode with the Linode API.

Linode plan types

Review your site to get an idea of your size requirements. Once you know how much space your site requires, review the available plan types to determine the plan that fits your needs.

Get the applicable id for your preferred plan type by running the following List Linode types operation. Replace $TOKEN with your Linode API access token:

Make note of your plan id, and save it for later (for example, g6-nanode-1).

Regions

Akamai Cloud is distributed across several data centers around the world. You need to determine the one that best fits your needs. For this high availability architecture in this tutorial, all of your Linode instances must be in the same region.

Run the List regions operation to review them, and store the id for the one you want to use (for example, us-central). Once again, replace $TOKEN with your Linode API access token:

2. Create and configure the primary instance

Run the Create a Linode operation to create your first instance to serve as the primary origin server. When building the POST object, replace the following values with your own. Leave all other values as their default:

$TOKEN: Replace this with your Linode API access token.
root_pass: Set a secure password you'll use to initially access the Linode over SSH as the default root user.
label: Set a name for your Linode instance.
type: Enter the id for your preferred Linode plan.
region: Enter the id for your preferred deployment region.

You can check the status of your Linode deployment using the List Linodes operation. Once booted, you can also use the List Linodes operation to get information about your instance like IP addresses, disk encryption status, and deployment region:

Install a LAMP stack on your primary

Once your primary Linode is created and booted, you'll need to secure your server and get a basic site up and running.

First, follow the steps in our Set up and secure a Linode guide to perform system updates and add a limited user account for your instance.

Then, move onto the Install and configure a LAMP stack guide to install a Linux, Apache2, MySQL, PHP (LAMP) stack, as well as configure your system's timezone, hostname, and basic firewall settings. These are free and open source components that power many modern web applications, and the individual components are designed to work together. Complete the steps by creating a virtual host for your domain.

Come back to this guide after your primary instance has been secured, your LAMP stack is configured, and your virtual host is set up.

Create a DNS entry

Your domain should point to the IP address of your primary Linode instance. To do this, you need to update your DNS with an A record entry. For example, if you were using a domain provider like Google Domains, you would log into your DNS control panel, and add a new custom record:

See our DNS Manager documentation to configure your DNS settings using our free DNS Manager service in Cloud Manager.

Set up a secure certificate

To set up high availability, one of your Linodes needs to serve as a secure point of entry, using HTTPS through a secure certificate. A LAMP stack set up on a Linode already includes this certificate, but may require manual renewal once it expires.

This section goes over the process for setting up Certbot on your primary instance. It also includes creating a secure, domain-validated (DV) certificate using Let's Encrypt as the certificate authority and enabling automatic renewal.

Log into your primary Linode instance. Replace IP_ADDRESS with the root password you entered when creating your Linode:
```
ssh root@IP_ADDRESS
```

Run the ufw status command to verify firewall settings. A LAMP stack should automatically enable firewall settings, and you should see the follow response:

Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
80/tcp (v6)                ALLOW       Anywhere (v6)             
443/tcp (v6)               ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

To ensure you have the latest version of Certbot, remove any previously installed versions:
```
sudo apt remove certbot
```
Use the snap utility to install the current version of Certbot:
```
sudo snap install --classic certbot
```
Configure a symbolic link to the Certbot directory using the ln command:
```
sudo ln -s /snap/bin/certbot /usr/bin/certbot
```
Request a certificate using Certbot:
```
sudo certbot --apache
```
When prompted, enter the email address the service will use to contact you with additional information. Replace john@docsassociates.com with your preferred email:
```
Enter email address (used for urgent renewal and security notices)  
  (Enter 'c' to cancel): john@docsassociates.com
```
When prompted, enter the domain name you want protected, replacing docassociates.com with your domain. If you have more than one, separate each domain with a whitespace:
```
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): docsassociates.com
```

The domains you enter must:

Be registered with an accredited registrar
Already exist on your Apache2 web server. See Apache2 quick config for details on adding your domains.

Once you enter your domain, the request is sent to Let's Encrypt to verify your domain and register the certificate:

Requesting a certificate for docsassociates.com

A successful completion message looks like this:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/docsassociates.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/docsassociates.com/privkey.pem
This certificate expires on 2025-12-21.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for docsassociates.com to /etc/apache2/sites-available/docsassociates.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://docsassociates.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Test your domain

Open a browser and type in your domain. Your site should now be secure as indicated by your domain being preceded with https://.

You may also see a browser indication that your site is now secured. For example, if using Chrome, the "Not secure" icon next to your domain should be replaced with a padlock icon.

Alternatively, you can run a curl against your domain in a terminal emulator to see if the output returns your domain location with https://:

curl -IL docsassociates.com
...
Location: https://docassociates.com/
..

Renew the certificate

A domain-validated certificate has a lifecycle of 90 days. Certbot automatically renews your certificate before its expiration date, but you may need to manually request an updated certificate if your site's configuration file on the Apache2 server changes. In this scenario, you can rerun the Certbot procedure in this section.

Optionally, you can test the automated renewal process, without affecting your current certificate.

3. Create standby #1

Create another Linode to serve as your first standby for failover. For the example in this tutorial, you can either clone the primary node as it currently exists (recommended), or you can make a new node by repeating the same steps you did when creating your primary node.

Cloning your primary instance can save you from needing to reconfigure your Apache2 web server. If creating new standby instances via the Marketplace, you'll also have to repeat the Apache2 quick config guide steps after they’re provisioned.

📘
In a true production environment, standby nodes are often identical to, and maintained alongside, primary nodes in clustered deployments (like Kubernetes clusters) to ensure data consistency. The deployment in this tutorial does not use a clustered deployment model for simplicity.

Option 1: Clone your primary Linode

Follow these steps, or see our Clone a Linode guide, if you want to clone your primary node.

Run the Clone a Linode operation, replacing the $TOKEN, $PASSWORD, and $REGION values with your own. Use the same plan type as your primary instance, and replace LINODE_ID with the id of your primary Linode. Note the name of your new standby instance in the label field:

curl -H "Content-Type: application/json" \
     -H "Authorization: Bearer $TOKEN" \
     -X POST -d '{
       "backups_enabled": false,
       "image": "linode/ubuntu22.04",
       "root_pass": "$PASSWORD",
       "booted": true,
       "label": "lamp-standby1-origin",
       "type": "g6-nanode-1",
       "region": "$REGION",
       "private_ip": true
    }' \
    https://api.linode.com/v4/linode/instances/LINODE_ID/clone

Check the status of your cloned Linode by running the List Linodes operation:

curl -X GET https://api.linode.com/v4/linode/instances \
    -H "Authorization: Bearer $TOKEN" 
    -H "Content-type: application/json" \

Option 2: Create a new standby Linode

If you wish to create a new standby node using the same steps as the primary instance, follow the same instructions as in the Create and configure the primary instance section, setting the below values:

root_pass: Set a unique password value using the same safe and secure recommendations.
label: Set it to something to differentiate this one as the first standby. For example: lamp-standby1-origin.
type: Use the same plan you did for your primary.
region: Set to the same region you set for the primary.

High availability switches between your Linodes to handle traffic and support failover. This means your standby #1 instance needs to be configured the same as your primary. Once booted, follow the same steps to Install and configure a LAMP stack on your standby #1 instance.

🚧
Don't set up another certificate
You do not need an additional certificate on either of your standby Linode instances. The certificate information generated on your primary Linode is used for securing your load balancing traffic in the Add network load balancing section.

4. Create standby #2

Having a second standby helps with failover and potential site maintenance. Repeat the steps you took to create standby #1 to add an additional standby Linode instance, this time editing the Linode label to differentiate from standby #1. For example: lamp-standby2-origin

5. Add network load balancing

NodeBalancers are Akamai’s cloud-based load balancing service. A NodeBalancer distributes client requests between Linodes to improve capacity, performance, and availability. This section goes over NodeBalancer setup to distribute requests between the Linode instances acting as your origin servers.

Get certificate information

When you set up HTTPS on the primary, a certificate and its private key were generated for the certificate. You need two pieces of information from the certificate to continue:

The contents of these files. To add the NodeBalancer, you need the actual contents of both the certificate and the private key files.
A SHA-1 fingerprint of the certificate. When you configure the Ion property to deliver your origin content on the CDN, you need a SHA-1 fingerprint of the certificate. A SHA-1 fingerprint generates a unique, fixed-length string from your certificate to act as an additional layer of security.

To get this information:

Log into your primary Linode instance as your limited sudo user in a new terminal session. Replace IP_ADDRESS with the IP of your primary Linode:
```
ssh user@IP_ADDRESS
```
View the contents of the fullchain.pem file containing the certificate, replacing docassociates.com with your domain:
```
sudo cat /etc/letsencrypt/live/docsassociates.com/fullchain.pem
```

Highlight and copy the entire contents of the file:

Open a new terminal session, and paste the entire contents of the file into a separate .txt file on your local machine. Save it as certificate.txt:
```
nano certificate.txt
```
Repeat the process for the privkey.pem file, replacing docassociates.com with your domain. This is the private key:
```
sudo cat /etc/letsencrypt/live/docsassociates.com/privkey.pem
```

Highlight and copy the entire contents of the file:

In your local terminal window, paste the contents of the file into another new .txt file. Save it as private.txt:
```
nano private.txt
```
In the terminal session on your primary instance, run the following openssl command to generate a SHA-1 fingerprint of your certificate:
```
sudo openssl x509 -noout -fingerprint -sha1 -inform pem -in /etc/letsencrypt/live/docsassociates.com/fullchain.pem
```
Store the SHA-1 fingerprint value on your local machine, omitting all of the colons:
```
sha1 Fingerprint=12:A3:45:67:89:BC:01:2D:EF::G3:H4:I5:67:8J:9K:0L:1M:NO:PQ
```

Set up load balancing

Once you have your certificate information, run the Create a NodeBalancer operation to set up your NodeBalancer. Replace the following values with your own and those of your Linodes, and leave all other values as their defaults:

$TOKEN: Replace this with your Linode API access token.
region: Use the same region as your primary and standby Linode instances.
label: Set a name for your NodeBalancer. For example: docassociates-origin
ssl_cert: Replace this with the contents of your certificate.txt file.
ssl_key: Replace this with the contents of your private.txt file.
nodes>address: Replace each IP address with the corresponding IPv4 addresses of your Linode instances.

You can check the status of your NodeBalancer deployment by running the List NodeBalancers operation, replacing $TOKEN with your API token:

curl -H "Content-Type: application/json" \
    -H "Authorization: Bearer $TOKEN" \
    https://api.linode.com/v4/nodebalancers

6. Get your site on your Linodes

🚧
This tutorial isn't intended for complex sites that integrate detailed databases or file systems. It offers an example of a basic Akamai Cloud environment using Linode instances to store a simple, secure site for delivery through the Akamai CDN.

The LAMP stack set up on your Linodes essentially creates a "blank canvas". This can be used to either build a new site or house your existing one.

Create a new basic site

You could develop your site directly on your primary Linode using PHP, MySQL for your database, and Apache2 as your web server. See the relevant product's documentation for details on their use.

Move your existing basic site

If you already have a simple site, you can migrate it to your primary Linode. With your Linodes deployed and LAMP installed, you'd need to:

Prepare and back up your current host.
Transfer data to your Linode.
Finish setting up your Linode.
Test your new environment. (This isn't for actual delivery, this is to test that your site is on the Linode.)

Duplicate your site on the standbys

Once you've created a new site or migrated an existing one to your primary, it needs to be duplicated and copied to your Standby #1 and Standby #2 instances. See our rsync documentation for tips and guidance for copying relevant files from one Linode to another.

What about maintenance?

There are several ways you can set up maintenance if you need to make changes to your site, including detailed replication scenarios that would reflect changes from your primary directly out to your standbys. TheseWhile these workflows are outside the scope of this document, the "primary + standby #1 + standby #2" model set up here allows for a manual method for maintenance. Below is an outline of a potential process you can follow.

Log in to your primary instance.
Stop Apache2 services using the below systemctl command:
```
systemctl stop apache2
```
This stops Apache2 on your primary instance. Standby #1 and standby #2 are still available to the NodeBalancer.
Make the necessary updates to your website on the primary.
Login to your standby #1 instance.
Stop Apache2 services. The service stops on standby #1, and standby #2 still remains available to the NodeBalancer.
Copy the changed files from the primary to standby #1 using rsync.
Start Apache2 services again on standby #1 by running this command:
```
systemctl start apache2
```
Login to standby #2.
Stop Apache2 services. Standby #1 is now available to the NodeBalancer, and your updates go live.
Copy the changed files from the primary to standby #2 using rsync.
Restart services on standby #2. It's now available to the NodeBlancer with your updated site.
Login to your primary and restart Apache2 services. All three of your Linodes are now available to the NodeBalancer with your updated site.

Alternatively, you can look into using a clustered Kubernetes, container-based deployment model. See our Linode Kubernetes Engine documentation for more information about using our managed Kubernetes service for containerized applications.

Additional resources

Secure your Linodes

See our Setting Up and Securing a Compute Instance guide for several recommendations, tips, and general best practices for properly securing your Linode instances beyond what’s covered in this tutorial.

Third-party resources

These are some additional third-party resources related to the software used in this guide's deployments:

📘
Since these are third-party resources, Akamai doesn't vouch for their accuracy or timeliness.