
Amazon Web Services (AWS) provides **Amazon S3** for file storage and **Amazon CloudFront** as a Content Delivery Network (CDN) to accelerate content delivery. Replacing your S3 file URLs with CloudFront URLs is an essential step to ensure your files load faster, more securely, and more professionally.

In this guide, we’ll walk through the complete process—from configuring CloudFront to updating your S3 file URLs.

---

## **Why Should You Replace S3 URLs With CloudFront URLs?**

Before we dive into the setup steps, here are the main reasons why CloudFront is highly recommended over directly serving files from S3:

- **Faster load times** thanks to global edge locations.
- **More stable performance** with content cached close to your users.
- **Stronger security** with Origin Access Control (OAC), HTTPS, and signed URLs.
- **More professional URLs**, like `https://cdn.yourdomain.com/image.jpg`.
- **Lower data transfer costs** when configured correctly.

---

# **Steps to Replace S3 URLs with CloudFront URLs**

---

## **1. Prepare Your S3 Bucket**

Make sure your S3 bucket contains the files you want to deliver through CloudFront.

**Checklist:**

- Ensure the bucket has the correct permissions.
- Upload all required files.
- You can keep **Block Public Access** enabled, because CloudFront will access the bucket using OAC.

---

## **2. Create a CloudFront Distribution (New UI – 5 Steps)**

When you click **Create distribution**, CloudFront now displays a new 5-step wizard:

- Step 1 – Choose a plan
- Step 2 – Get started
- Step 3 – Specify origin
- Step 4 – Enable security
- Step 5 – Review and create

Below is the detailed walkthrough for each step.

---

## **Step 1 – Choose a plan**

You’ll see several plan options:

- **Free – $0/month**
- **Pro – $15/month**
- **Business – $200/month**
- **Premium – $1000/month**

And at the bottom:

- **Pay as you go (Pricing varies with usage)**

For standard CDN usage (websites, apps, static assets), the best option is:

✅ **Pay as you go** — no fixed monthly cost, pay only for what you use.

Click **Next** to continue.

![Step 01](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-01.webp)

---

## **Step 2 – Get started**

Here you define the basic configuration of your distribution.

### Fields to complete:

1. **Distribution name**
   Use a clear, identifiable name, for example:

   ```
   s3-ferry-example
   ```

2. **Description (optional)**
   You may add a short note, or leave it empty.

3. **Distribution type**
   Choose:

   ✅ **Single website or app**

   (Use Multi-tenant only for SaaS platforms with shared architecture across multiple domains.)

4. **Domain (optional)**
   If you have a Route 53 domain and want to attach a custom CDN domain immediately, you may enter it here.
   If your DNS is hosted elsewhere, you can skip this for now and set it up later using your DNS provider + ACM SSL.

Click **Next**.

![Step 02](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-02.webp)

---

## **Step 3 – Specify origin**

This is where you connect CloudFront to your S3 bucket.

### 1. Origin type

Select:
✅ **Amazon S3**

### 2. S3 origin

Choose or type your S3 bucket endpoint, for example:

```
ferry-example.s3.ap-southeast-1.amazonaws.com
```

You can also use **Browse S3** to select your bucket.

### 3. Origin path (optional)

If you want CloudFront to serve only a specific folder:

```
/path
```

Examples: `/uploads`, `/assets/images`
Leave this empty to serve the entire bucket.

### 4. Allow private S3 bucket access to CloudFront

This is critical for security.

Check:

✅ **Allow private S3 bucket access to CloudFront – Recommended**

This ensures:

- Your bucket remains **private** (Block Public Access ON)
- CloudFront automatically updates bucket policies so only this distribution can access it

### 5. Origin & cache settings

Default settings are ideal:

- **Origin settings** → ✅ _Use recommended origin settings_
- **Cache settings** → ✅ _Use recommended cache settings tailored to serving S3 content_

Click **Next**.

![Step 03](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-03.webp)

---

## **Step 4 – Enable security**

This step configures Web Application Firewall (WAF) protections.

You have two choices:

### 1. ✅ **Enable security protections**

Includes:

- Protection against common web vulnerabilities
- Malicious traffic filtering
- IP blocking
- Optional Layer 7 DDoS protection (Recommended)

Best for dynamic apps, APIs, login pages, or any high-traffic service.

### 2. ❌ **Do not enable security protections**

Good option if you're serving **static files only** and want to reduce cost.

### Optional:

- **Use monitor mode** — view what would be blocked before enforcing it.

Click **Next** after choosing.

![Step 04](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-04.webp)

---

## **Step 5 – Review and create**

CloudFront will display a summary of your configuration:

### General configuration

- Distribution name
- Billing (e.g., Pay-as-you-go)

### Origin

- S3 origin (bucket + region)
- Origin path
- CloudFront access: **Yes**

### Cache settings

- Using recommended S3-optimized cache settings

### Security

- Whether WAF protections are enabled

If everything looks correct:

✅ Click **Create distribution**

![Step 05](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-05.webp)

Wait a few minutes until the status becomes **Enabled**.

---

# **Conclusion**

Updating your S3 URLs to CloudFront is one of the most effective ways to improve website speed, reliability, and security. The process is simple: create a CloudFront distribution, link it with your S3 bucket, and replace your S3 URLs with your new CloudFront domain.



Amazon S3 (Simple Storage Service) is a popular cloud storage service from AWS that allows users to store and retrieve any amount of data at any time. Whether you're hosting static websites, storing backups, or serving media content, S3 is a reliable and scalable solution.

In this guide, you'll learn how to create an S3 bucket step-by-step using the AWS Console.

---

## Step 1: Log in to AWS Console

Start by logging in to your AWS account via the [AWS Management Console](https://aws.amazon.com/console/).

![image 1](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-01.webp?updatedAt=1733887150760)

---

## Step 2: Open the Amazon S3 Service

After logging in, search for **S3** in the search bar at the top and click the **S3** service.

![image 2](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-02.webp?updatedAt=1733887150760)

---

## Step 3: Create a New Bucket

- Click the **Create bucket** button.  
- Enter a unique **Bucket name** (must be globally unique).  
- Under **Object Ownership**, choose **ACLs disabled (recommended)** to simplify permissions.

![image 3](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-03.webp?updatedAt=1733887150760)

---

## Step 4: Configure Encryption

- Scroll down to the **Default encryption** section.  
- Choose **Amazon S3 managed keys (SSE-S3)**.  
- Enable the **Bucket Key** to reduce the cost of encryption requests.

![image 4](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-04.webp?updatedAt=1733887150760)

---

## Step 5: Finalize and View Your Bucket

After completing the setup, your new bucket will appear in the S3 bucket list.

![image 5](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-05.webp?updatedAt=1733887150760)

Click the bucket name to open it and start uploading files, setting permissions, or enabling static website hosting.

![image 6](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-06.webp?updatedAt=1733887150760)

---

## Conclusion

Setting up an S3 bucket is simple and essential for many AWS-powered applications. With just a few clicks, you can start storing data securely in the cloud. Don't forget to manage access policies and monitor your storage usage for optimal performance and cost.

Need help with setting permissions or enabling static site hosting? Stay tuned for our upcoming guides on advanced S3 configurations!


Enabling HTTPS on your website is crucial for security, SEO, and user trust. Thankfully, Let’s Encrypt offers free SSL/TLS certificates that are easy to set up on an Nginx server. In this tutorial, we’ll walk through how to secure your Nginx server using Let’s Encrypt on Ubuntu.

---

## Step 1: Check Your Website Before SSL

Before adding SSL, your website is likely still served over plain HTTP.

Example:
`http://jadifullstack.id`

![Image 1](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-01.webp?updatedAt=1733852578858)

---

## Step 2: Install Certbot and the Nginx Plugin

Make sure your system is up to date:

```bash
sudo apt update
sudo apt install certbot python3-certbot-nginx
```

Certbot is the tool that will communicate with Let’s Encrypt and configure Nginx automatically.

---

## Step 3: Request an SSL Certificate

Run the following command to request and install your SSL certificate:

```bash
sudo certbot --nginx -d jadifullstack.id
```

If successful, you'll see a confirmation message:

> "Successfully received certificate"

![Image 2](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-02.webp?updatedAt=1733852578858)

---

## Step 4: Verify HTTPS is Working

After a successful setup, your website will now be accessible via HTTPS.

Example:
`https://jadifullstack.id`

![Image 3](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-03.webp?updatedAt=1733852578858)

Check that your browser shows a secure padlock and that HTTP requests are redirected to HTTPS.

---

## Step 5: Enable Auto Renewal

Let’s Encrypt certificates expire every 90 days. Certbot makes it easy to auto-renew them.

You can verify the auto-renewal configuration with this command:

```bash
sudo certbot renew --dry-run
```

To schedule auto-renewal using `cron`, run:

```bash
crontab -e
```

Then add the following line to renew the certificate daily at noon:

```bash
0 12 * * * /usr/bin/certbot renew --quiet
```

![Image 4](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-04.webp?updatedAt=1733852578858)

---

## Conclusion

Now your Ubuntu VPS running Nginx is secured with HTTPS using a free SSL certificate from Let’s Encrypt. This simple setup improves trust, SEO ranking, and data protection. Always monitor your certificate expiration or use Certbot's auto-renewal to avoid disruptions.

Want to take it further? Consider setting up a redirect from HTTP to HTTPS or enabling HTTP/2 for better performance!





When launching an EC2 instance, the public IP address assigned to it can change if the instance is stopped and restarted. To avoid this, AWS provides **Elastic IP addresses**—a static IPv4 address designed for dynamic cloud computing.

In this guide, we’ll show you how to allocate and associate an Elastic IP address with your EC2 instance.

---

## Step 1: Allocate a New Elastic IP Address

From the AWS Management Console, go to the **EC2 Dashboard**, then select **Elastic IPs** from the sidebar. Click on **Allocate Elastic IP address** and confirm.

![Image 1](https://ik.imagekit.io/n1hqrcegw/articles/panduan-menggunakan-elastic-ip-address-ec2-instance/gambar-01.webp?updatedAt=1733759701308)

---

## Step 2: Associate the Elastic IP with Your EC2 Instance

Once the IP is allocated, select it from the list and click **Actions → Associate Elastic IP address**.

* In the **Resource type**, choose **Instance**.
* In **Instance**, select the EC2 instance you want to assign the IP to.
* Click **Associate** to finalize the configuration.

![Image 2](https://ik.imagekit.io/n1hqrcegw/articles/panduan-menggunakan-elastic-ip-address-ec2-instance/gambar-02.webp?updatedAt=1733759701308)

---

## Step 3: Verify IP Assignment

Go to your **EC2 Instances dashboard** and confirm that the public IP has been updated with your new Elastic IP.

This IP will remain the same even if you stop and start the instance.

![Image 3](https://ik.imagekit.io/n1hqrcegw/articles/panduan-menggunakan-elastic-ip-address-ec2-instance/gambar-03.webp?updatedAt=1733759701308)

---

## Conclusion

Elastic IP addresses are essential for maintaining a consistent public IP for your cloud services, especially for production environments. Remember that AWS charges for unused Elastic IPs, so always release any IP addresses that are no longer in use.

With this setup, your EC2 instance is now more stable and accessible under a static IP.




If you're hosting a website or application on AWS, using Amazon Route 53 as your DNS provider gives you full control over routing traffic. In this guide, you'll learn how to move your domain's name servers to Route 53.

---

## Step 1: Create a Public Hosted Zone in Route 53

Go to the AWS Route 53 Console. Click on **Hosted zones** in the sidebar, then choose **Create hosted zone**.

* Enter your **domain name**.
* Choose **Public hosted zone**.
* Click **Create hosted zone**.

![Image 1](https://ik.imagekit.io/n1hqrcegw/articles/tingkatkan-kinerja-domain-cara-pindahkan-name-server-route-53/gambar-01.webp?updatedAt=1733752674448)

---

## Step 2: View Your Route 53 NS Records

After creating the hosted zone, Route 53 automatically generates several records, including the **NS (Name Server)** records. These are the name servers you need to use for your domain.

![Image 2](https://ik.imagekit.io/n1hqrcegw/articles/tingkatkan-kinerja-domain-cara-pindahkan-name-server-route-53/gambar-02.webp?updatedAt=1733752674448)

---

## Step 3: Update Name Servers on Your Domain Registrar (GoDaddy Example)

Log in to your domain registrar (e.g., GoDaddy), go to your domain settings, and choose **Manage DNS**.

* Scroll to **Nameservers** and choose: **I'll use my own nameservers**.
* Copy and paste the NS records from Route 53 into the fields.
* Save the changes.

![Image 3](https://ik.imagekit.io/n1hqrcegw/articles/tingkatkan-kinerja-domain-cara-pindahkan-name-server-route-53/gambar-03.webp?updatedAt=1733752674448)

Note: DNS changes can take up to 48 hours to fully propagate.

---

## Conclusion

Using AWS Route 53 as your DNS provider helps ensure high availability, fast response times, and tight integration with other AWS services. After updating your nameservers, you can manage DNS records directly from the Route 53 dashboard.

Be sure to monitor your DNS configuration and test it using tools like `dig`, `nslookup`, or online DNS checkers to verify the update was successful.



Amazon Web Services (AWS) offers a wide range of **EC2 instance types**, each designed for specific workloads. If you have ever wondered what those names like **t2.medium**, **m5.large**, **c6i.32xlarge**, or **g5.2xlarge** mean, this guide will help you decode them and choose the best fit for your application.

---

## What Is an EC2 Instance?
An **EC2 instance** is a virtual server running on AWS infrastructure. Each instance type has a specific balance of **CPU, memory, storage, and networking capacity**, optimized for different use cases such as general computing, machine learning, or high-performance databases.

---

## How to Read EC2 Instance Names
An instance name like `c6i.32xlarge` can be broken down into three main parts:

- **Prefix letter(s)** → indicates the **instance family** (e.g., `t`, `m`, `c`, `g`).
- **Generation number** → shows the **version** (e.g., `6` is newer than `5`).
- **Suffix / size** → defines **hardware details** (e.g., `.large`, `.xlarge`, `.metal`).

Example:  
- `c6i.32xlarge` → **Compute Optimized**, **6th generation**, Intel CPU (`i`), **32xlarge size**.

---

## EC2 Instance Families Explained

### 1. General Purpose
- **t Family** – Burstable general purpose (e.g., `t2`, `t3`, `t4g`).  
  Best for: Low-traffic websites, dev/test workloads.  

- **m Family** – Balanced general purpose (e.g., `m5`, `m6i`, `m7g`).  
  Best for: Application servers, small to medium databases, general workloads.

---

### 2. Compute Optimized
- **c Family** – High CPU power compared to memory (e.g., `c5`, `c6i`).  
  Best for: High-performance computing, batch processing, game servers.  

---

### 3. Memory Optimized
- **r Family** – High memory per vCPU (e.g., `r5`, `r6g`).  
  Best for: In-memory caches, big data, real-time analytics.  

- **x Family** – Extra memory (e.g., `x1e`, `x2idn`).  
  Best for: Large in-memory databases like SAP HANA.  

- **z Family** – High frequency CPUs + large memory (e.g., `z1d`).  
  Best for: EDA, financial simulations, latency-sensitive workloads.  

---

### 4. Storage Optimized
- **d Family** – Dense HDD storage (e.g., `d2`).  
  Best for: Data warehouses, Hadoop, distributed storage.  

- **i Family** – High IOPS NVMe SSD (e.g., `i3`, `i4i`).  
  Best for: NoSQL databases, OLTP.  

- **h Family** – High throughput HDD (e.g., `h1`).  
  Best for: Data-intensive workloads with sequential reads/writes.  

---

### 5. Accelerated Computing
- **g Family** – GPU for graphics/ML inference (e.g., `g4dn`, `g5`).  
  Best for: Machine learning inference, 3D rendering, remote workstations.  

- **p Family** – GPU for ML training/HPC (e.g., `p3`, `p4d`).  
  Best for: Deep learning training, scientific computing.  

- **f Family** – FPGA instances (e.g., `f1`).  
  Best for: Custom hardware acceleration.  

- **inf Family** – AWS Inferentia chip (e.g., `inf1`).  
  Best for: AI inference at low cost.  

- **trn Family** – AWS Trainium chip (e.g., `trn1`).  
  Best for: Deep learning training at scale.  

---

## Instance Size Naming
Each instance has multiple sizes, for example:

- `.nano`, `.micro`, `.small` – Very small workloads.  
- `.medium`, `.large` – Moderate workloads.  
- `.xlarge`, `.2xlarge`, `.4xlarge` … `.32xlarge` – Increasing CPU & RAM.  
- `.metal` – Bare metal access (direct hardware).  

Example:  
- `m6i.large` → 2 vCPU, 8 GB RAM.  
- `m6i.32xlarge` → 128 vCPU, 512 GB RAM.  

---

## Choosing the Right Instance
When selecting an EC2 instance, consider:

1. **Workload type** – Is it CPU-bound, memory-intensive, or GPU-dependent?  
2. **Cost efficiency** – Graviton (`g`) instances often provide better price/performance.  
3. **Scalability** – Start small and scale up as demand grows.  
4. **Storage needs** – Do you need high IOPS SSDs (`i` family) or dense HDDs (`d` family)?  

---

## Quick Reference Table

| Family | Optimized For           | Example Instances | Best Use Cases |
|--------|--------------------------|------------------|----------------|
| t      | Burstable General        | t3, t4g          | Dev/test, small apps |
| m      | Balanced General         | m5, m6i, m7g     | Web/app servers, DBs |
| c      | Compute                  | c5, c6i          | HPC, game servers |
| r      | Memory                   | r5, r6g          | In-memory DB, big data |
| x      | Extra Memory             | x1e, x2idn       | SAP HANA, large DBs |
| z      | High Frequency + Memory  | z1d              | Financial sims, EDA |
| d      | Dense Storage            | d2               | Data warehouse |
| i      | High IOPS SSD            | i3, i4i          | NoSQL, OLTP |
| g      | GPU (Graphics/ML)        | g4dn, g5         | ML inference, 3D |
| p      | GPU (Training)           | p3, p4d          | DL training, HPC |
| f      | FPGA                     | f1               | Hardware accel |
| inf    | Inferentia (AI infer.)   | inf1             | AI inference |
| trn    | Trainium (AI training)   | trn1             | AI training |

---

## Final Thoughts
AWS EC2 instance names may look confusing at first, but once you understand the **family, generation, and size**, it becomes easier to choose the right one. Whether you need a **cheap burstable server (t2)**, a **balanced general-purpose option (m5)**, a **compute powerhouse (c6i)**, or a **GPU instance (g5)**, AWS has a type tailored for your workload.




### 🔧 **Service Management (Ubuntu-based systems)**

| Command                             | Description                             |
| ----------------------------------- | --------------------------------------- |
| `sudo systemctl start supervisor`   | Start the Supervisor service            |
| `sudo systemctl stop supervisor`    | Stop the Supervisor service             |
| `sudo systemctl restart supervisor` | Restart Supervisor                      |
| `sudo systemctl status supervisor`  | Check the status of Supervisor          |
| `sudo systemctl enable supervisor`  | Enable Supervisor to run at boot        |
| `sudo systemctl disable supervisor` | Disable Supervisor from running at boot |

---

### ⚙️ **Supervisor CLI Commands**

These use the `supervisorctl` command:

| Command                                | Description                                          |
| -------------------------------------- | ---------------------------------------------------- |
| `sudo supervisorctl`                   | Enter Supervisor interactive mode                    |
| `sudo supervisorctl status`            | View the status of all managed processes             |
| `sudo supervisorctl start <program>`   | Start a specific program                             |
| `sudo supervisorctl stop <program>`    | Stop a specific program                              |
| `sudo supervisorctl restart <program>` | Restart a specific program                           |
| `sudo supervisorctl reread`            | Reread config files (does **not** apply changes yet) |
| `sudo supervisorctl update`            | Apply changes after `reread` (add/remove programs)   |
| `sudo supervisorctl reload`            | Restart Supervisor and all managed processes         |
| `sudo supervisorctl shutdown`          | Gracefully shut down Supervisor daemon               |

---

### 📁 **Supervisor Config Locations (Ubuntu)**

| Path                               | Description                                        |
| ---------------------------------- | -------------------------------------------------- |
| `/etc/supervisor/supervisord.conf` | Main Supervisor config file                        |
| `/etc/supervisor/conf.d/`          | Directory to store individual program config files |

---

### 🛠️ **Example Workflow After Adding a New Program**

```bash
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start your_program_name
```




### 🚀 **Basic Process Management**

| **Command**                                            | **Description**                                    |
| ------------------------------------------------------ | -------------------------------------------------- |
| `pm2 start app.js`                                     | Start a Node.js application                        |
| `pm2 start app.js --name my-app`                       | Start the app with a custom process name           |
| `pm2 list`                                             | List all running processes managed by PM2          |
| `pm2 show <id or name>` or `pm2 describe <id or name>` | Show detailed information about a specific process |
| `pm2 restart <id or name>`                             | Restart a specific process                         |
| `pm2 reload <id or name>`                              | Gracefully reload a process (zero downtime)        |
| `pm2 stop <id or name>`                                | Stop a specific process                            |
| `pm2 delete <id or name>`                              | Delete a process from the PM2 process list         |
| `pm2 delete all`                                       | Remove all processes from PM2 management           |


---

### 🔁 **Startup & Auto-Restart**

| Command         | Description                                              |
| --------------- | -------------------------------------------------------- |
| `pm2 startup`   | Generate and configure PM2 to launch on system boot      |
| `pm2 save`      | Save current process list for automatic reload on reboot |
| `pm2 resurrect` | Restore processes saved via `pm2 save`                   |

---

### 📈 **Monitoring & Logs**

| **Command**             | **Description**                                     |
| ----------------------- | --------------------------------------------------- |
| `pm2 monit`             | Launch PM2's real-time process monitoring dashboard |
| `pm2 logs`              | Show logs for all processes                         |
| `pm2 logs <id or name>` | Show logs for a specific process                    |
| `pm2 flush`             | Clear all logs                                      |
| `pm2 reloadLogs`        | Reload logs in real-time                            |

---

### 🛠️ **Miscellaneous**

| **Command**                      | **Description**                                   |
| -------------------------------- | ------------------------------------------------- |
| `pm2 env <id or name>`           | Show environment variables for a specific process |
| `pm2 reload ecosystem.config.js` | Reload all apps defined in an ecosystem file      |
| `pm2 start ecosystem.config.js`  | Start all apps from an ecosystem file             |





A complete and beginner-friendly guide to install **Certbot Let’s Encrypt SSL** on **Ubuntu servers with NGINX**, enabling free **HTTPS encryption** with **automatic certificate renewal**.

---

## 📦 Installing Certbot on Ubuntu 16.04

For users running Ubuntu 16.04, execute the following commands:

```bash
apt-get update
sudo apt-get install certbot
sudo apt-get install python-certbot-nginx
```

---

## 📦 Installing Certbot on Ubuntu 18.04 and Later

For Ubuntu 18.04 or any newer version, run the following:

```bash
apt-get update
sudo apt-get install certbot
sudo apt-get install python3-certbot-nginx
```

---

## 🌐 Obtain a Let’s Encrypt SSL Certificate for NGINX

Once Certbot is installed, use this command to **automatically configure HTTPS for your domain**:

```bash
sudo certbot --nginx -d example.com
```

Replace `example.com` with your actual domain name.

---

## 🔁 Automatically Renew Let’s Encrypt SSL Certificates

To ensure your SSL certificates are **renewed automatically**, add a cron job as follows:

### Edit Crontab

```bash
crontab -e
```

### Add the Following Line

```bash
0 12 * * * /usr/bin/certbot renew --quiet
```

This command runs the renewal process **daily at 12:00 PM**.

---

## ✅ Conclusion

Your website is now secured with **free HTTPS using Let’s Encrypt**, and the SSL certificate will automatically renew without manual intervention.



### 🔧 **Service Management**

Use `sudo` if you're not logged in as root.

| Command                        | Description                                       |
| ------------------------------ | ------------------------------------------------- |
| `sudo systemctl start nginx`   | Start the Nginx service                           |
| `sudo systemctl stop nginx`    | Stop the Nginx service                            |
| `sudo systemctl restart nginx` | Restart Nginx and reload all configs              |
| `sudo systemctl reload nginx`  | Reload config without dropping active connections |
| `sudo systemctl status nginx`  | Check the current status of Nginx                 |
| `sudo systemctl enable nginx`  | Enable Nginx to start at boot                     |
| `sudo systemctl disable nginx` | Disable Nginx from auto-starting at boot          |

---

### ⚙️ **Configuration & Testing**

| Command                | Description                                 |
| ---------------------- | ------------------------------------------- |
| `sudo nginx -t`        | Test Nginx configuration for syntax errors  |
| `sudo nginx -s reload` | Reload Nginx via CLI                        |
| `sudo nginx -s stop`   | Stop Nginx via CLI                          |
| `sudo nginx -s quit`   | Gracefully shut down Nginx                  |
| `nginx -v`             | Show Nginx version                          |
| `nginx -V`             | Show version with build options and modules |

---

### 📁 **Default Configuration Paths (Ubuntu)**

| Path                          | Description                                                    |
| ----------------------------- | -------------------------------------------------------------- |
| `/etc/nginx/nginx.conf`       | Main Nginx config file                                         |
| `/etc/nginx/sites-available/` | Directory for available virtual host configs                   |
| `/etc/nginx/sites-enabled/`   | Directory for enabled sites (symlinked from `sites-available`) |
| `/var/www/html/`              | Default web root directory                                     |

---

### 🛠️ **Extra Tips**

* After editing the config:

  ```bash
  sudo nginx -t && sudo systemctl reload nginx
  ```

* To view logs:

  ```bash
  tail -f /var/log/nginx/access.log
  tail -f /var/log/nginx/error.log
  ```


Ferry Dermawan

Blog

Shorts