Laravel Vue AWS EC2

### 1. **Setting Up AWS EC2 Instance**

1. **Launch an EC2 Instance:**
– Go to AWS Management Console → EC2 → Launch Instance.
– Choose an Ubuntu-based AMI (e.g., `Ubuntu 20.04 LTS` or `Ubuntu 22.04 LTS`).
– Select the desired instance type (e.g., `t2.micro` for testing).
– Set up key pairs for SSH access.

2. **Install PHP 8.3 and Necessary Extensions:**
SSH into your EC2 instance and install PHP 8.3 along with necessary extensions.

sudo add-apt-repository ppa:ondrej/php
   sudo apt-get update
   sudo apt-get install php8.3 php8.3-cli php8.3-fpm php8.3-mysql php8.3-xml php8.3-mbstring php8.3-curl php8.3-bcmath

3. **Install Composer:**
Composer is required to manage PHP dependencies.

curl -sS https://getcomposer.org/installer | php
   sudo mv composer.phar /usr/local/bin/composer

4. **Install Node.js 21:**
Follow the steps to install Node.js version 21.

curl -fsSL https://deb.nodesource.com/setup_21.x | sudo -E bash -
   sudo apt-get install -y nodejs

5. **Install Nginx (Optional) and Configure Web Server:**
If you're using Nginx as a reverse proxy for PHP-FPM:

sudo apt-get install nginx
   sudo service nginx start

Make sure your Nginx configuration points to the correct `public` folder of your Laravel application.

### 2. **Bitbucket Pipeline Configuration**

You can use Bitbucket Pipelines for continuous deployment to your EC2 instance without IAM users. Below are the steps for setting up deployment:

1. **Create SSH Keys for Deployment:**
Generate SSH keys on your local machine (or Bitbucket Pipelines).

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Add the **private key** to Bitbucket Pipelines as a secure environment variable (e.g., `SSH_PRIVATE_KEY`) and the **public key** to the EC2 instance's `~/.ssh/authorized_keys` for the user you will use to deploy (e.g., `ubuntu`).

2. **Configure Bitbucket Pipeline YAML:**
Here is an example of a `bitbucket-pipelines.yml` file that deploys to EC2 using SSH keys without IAM user permissions:

image: node:21

   pipelines:
     default:
       - step:
           name: Build & Deploy
           caches:
             - node
           script:
             - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add -
             - mkdir -p ~/.ssh
             - chmod 700 ~/.ssh
             - echo "$EC2_SSH_PUBLIC_KEY" > ~/.ssh/authorized_keys
             - chmod 600 ~/.ssh/authorized_keys
             - git clone https://your-bitbucket-repository-url
             - cd your-project-directory
             - npm install
             - npm run build
             - composer install --no-dev --optimize-autoloader
             - rsync -avz --exclude=.git --exclude=node_modules ./ ubuntu@your-ec2-public-ip:/path/to/your/project
             - ssh -o StrictHostKeyChecking=no ubuntu@your-ec2-public-ip "cd /path/to/your/project && php artisan migrate && php artisan config:cache"

3. **Configure SSH for Bitbucket Pipelines:**
The key lines in the pipeline configuration involve adding the private SSH key to the `ssh-agent` and ensuring the EC2 public key is added to the `authorized_keys` file on the EC2 server.

4. **Deploy Laravel App:**
– The pipeline builds your Laravel application and deploys it to the EC2 instance using `rsync`.
– It installs the necessary dependencies (`composer install`, `npm install`, etc.) and runs Laravel commands (`php artisan migrate` and `php artisan config:cache`) after deployment.

### 3. **Security Best Practices**

Since you're not using IAM roles, here are some security recommendations:
– Use SSH key pairs for authentication instead of password-based login.
– Restrict EC2 instance access to only the IPs or ranges you trust.
– Make sure `~/.ssh/authorized_keys` on the EC2 instance only contains trusted public keys.
– Secure sensitive data like database credentials and environment variables through environment configuration in Bitbucket Pipelines.

Let me know if you need more details on any specific step!

### 1. **Add the Private Key to Bitbucket Pipelines**

The private SSH key will be used in Bitbucket Pipelines for authentication when connecting to the EC2 instance. Here’s how to add it as a secure environment variable in Bitbucket:

#### Steps:
1. **Generate SSH Keys** (if not done yet):
If you haven't already, generate a new SSH key pair using the following command on your local machine (or from Bitbucket Pipelines itself):

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

– This will create two files: `id_rsa` (private key) and `id_rsa.pub` (public key).

2. **Add the Private Key to Bitbucket**:
– Log in to your Bitbucket account.
– Navigate to your repository.
– Go to **Repository Settings** → **Pipeline settings** → **Environment variables**.
– Add a new environment variable:
– **Name**: `SSH_PRIVATE_KEY`
– **Value**: Paste the contents of your `id_rsa` (private key file). Ensure there are no extra spaces or newlines before and after the key.
– **Type**: Secure (this ensures the private key is hidden in the logs).

#### Example:
The private key (`id_rsa`) might look something like this:

-----BEGIN OPENSSH PRIVATE KEY-----
<your private key contents>
-----END OPENSSH PRIVATE KEY-----

Ensure there are no extra newlines or spaces in the Bitbucket environment variable input.

### 2. **Add the Public Key to the EC2 Instance’s `~/.ssh/authorized_keys`**

The public key (`id_rsa.pub`) will be added to the EC2 instance so that it can authenticate the incoming SSH connection from Bitbucket Pipelines.

#### Steps:
1. **Copy the Public Key**:
– On your local machine, open the `id_rsa.pub` file or use the `cat` command to view it:

cat ~/.ssh/id_rsa.pub

– Copy the entire key (it will start with `ssh-rsa` and end with your email address).

2. **Log in to Your EC2 Instance**:
SSH into your EC2 instance using an existing key pair or another method (e.g., EC2 Console).

ssh -i /path/to/your/key.pem ubuntu@<your-ec2-ip>

3. **Add the Public Key to the `authorized_keys` File**:
On your EC2 instance, perform the following steps:
– Ensure the `.ssh` directory exists in your user’s home directory:

mkdir -p ~/.ssh
     chmod 700 ~/.ssh

– Add the public key to the `authorized_keys` file:

echo "<your-public-key>" >> ~/.ssh/authorized_keys
     chmod 600 ~/.ssh/authorized_keys

Replace “ with the public key contents from `id_rsa.pub`.

4. **Verify the Permissions**:
Ensure the permissions are correct on the `.ssh` directory and `authorized_keys` file:

chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys

### 3. **Update Bitbucket Pipeline to Use SSH Key**

Now that the private key is securely stored in Bitbucket Pipelines and the public key is in the EC2 instance, modify your `bitbucket-pipelines.yml` file to use the SSH key for authentication.

#### Example `bitbucket-pipelines.yml`:

image: node:21

pipelines:
  default:
    - step:
        name: Build & Deploy
        caches:
          - node
        script:
          - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add -
          - mkdir -p ~/.ssh
          - chmod 700 ~/.ssh
          - echo "$EC2_SSH_PUBLIC_KEY" > ~/.ssh/authorized_keys
          - chmod 600 ~/.ssh/authorized_keys
          - git clone https://your-bitbucket-repository-url
          - cd your-project-directory
          - npm install
          - npm run build
          - composer install --no-dev --optimize-autoloader
          - rsync -avz --exclude=.git --exclude=node_modules ./ ubuntu@your-ec2-public-ip:/path/to/your/project
          - ssh -o StrictHostKeyChecking=no ubuntu@your-ec2-public-ip "cd /path/to/your/project && php artisan migrate && php artisan config:cache"

In this example, the `SSH_PRIVATE_KEY` environment variable is passed into the pipeline, decrypted, and added to the SSH agent for authentication. Make sure the `authorized_keys` file is only modified in a secure manner to avoid security risks.

Now, when you push changes to Bitbucket, the pipeline will use SSH to deploy the changes to your EC2 instance.

Let me know if you need further clarification or assistance!

Here’s how you can set up Bitbucket Pipelines to deploy from a specific branch:

### Example of Deploying from a Specific Branch

Let’s say you want to deploy when changes are pushed to the `main` or `develop` branch.

#### Update `bitbucket-pipelines.yml`

image: node:21

pipelines:
  branches:
    main:
      - step:
          name: Build & Deploy to EC2 (Main)
          caches:
            - node
          script:
            - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add -
            - mkdir -p ~/.ssh
            - chmod 700 ~/.ssh
            - echo "$EC2_SSH_PUBLIC_KEY" > ~/.ssh/authorized_keys
            - chmod 600 ~/.ssh/authorized_keys
            - git clone https://your-bitbucket-repository-url
            - cd your-project-directory
            - npm install
            - npm run build
            - composer install --no-dev --optimize-autoloader
            - rsync -avz --exclude=.git --exclude=node_modules ./ ubuntu@your-ec2-public-ip:/path/to/your/project
            - ssh -o StrictHostKeyChecking=no ubuntu@your-ec2-public-ip "cd /path/to/your/project && php artisan migrate && php artisan config:cache"
          
    develop:
      - step:
          name: Build & Deploy to EC2 (Develop)
          caches:
            - node
          script:
            - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add -
            - mkdir -p ~/.ssh
            - chmod 700 ~/.ssh
            - echo "$EC2_SSH_PUBLIC_KEY" > ~/.ssh/authorized_keys
            - chmod 600 ~/.ssh/authorized_keys
            - git clone https://your-bitbucket-repository-url
            - cd your-project-directory
            - npm install
            - npm run build
            - composer install --no-dev --optimize-autoloader
            - rsync -avz --exclude=.git --exclude=node_modules ./ ubuntu@your-ec2-public-ip:/path/to/your/project
            - ssh -o StrictHostKeyChecking=no ubuntu@your-ec2-public-ip "cd /path/to/your/project && php artisan migrate && php artisan config:cache"

### Explanation:

– **Branch-specific Pipelines**:
– The `pipelines` key allows you to define different pipelines for different branches. In this example, the pipeline is triggered for the `main` and `develop` branches.
– For each branch, you have a specific step that builds and deploys the application to the EC2 instance.

– **`branches` Section**:
– Under `branches`, you can define pipelines that run only when specific branches are pushed to (like `main`, `develop`, or any feature branches).
– In this case, the pipeline will only trigger deployment if changes are pushed to the `main` or `develop` branch.

– **Deploy to EC2**:
– The steps in the pipeline (installing dependencies, running builds, syncing files, etc.) remain the same as before, but now they will only run for the specified branches (`main` or `develop`).

### Additional Branches (Optional):
If you want to deploy from multiple branches (e.g., `staging`, `feature/*`), you can add additional pipeline configurations:

pipelines:
  branches:
    main:
      - step:
          name: Build & Deploy to EC2 (Main)
          script: ...
          
    develop:
      - step:
          name: Build & Deploy to EC2 (Develop)
          script: ...

    staging:
      - step:
          name: Build & Deploy to EC2 (Staging)
          script: ...
    
    "feature/*":
      - step:
          name: Build & Deploy to EC2 (Feature branches)
          script: ...

This configuration will deploy from:
– `main`
– `develop`
– `staging`
– Any branch that starts with `feature/`

### Notes:
– **Security**: Make sure to handle environment variables securely. `SSH_PRIVATE_KEY` and any sensitive information should be stored in Bitbucket's secure environment variables (as mentioned before).
– **Deploying from Pull Requests**: If you want to deploy changes from a pull request, you can set up a pipeline to trigger on `pull-requests` as well. But generally, deployments happen from specific branches like `main` or `develop`.

By setting up your pipeline this way, you ensure that the right code is deployed based on the branch that is pushed. Let me know if you need further assistance!

### `bitbucket-pipelines.yml` for Deployment from `main` Branch Only

image: node:21

pipelines:
  branches:
    main:
      - step:
          name: Build & Deploy to EC2
          caches:
            - node
          script:
            # Add SSH private key to the SSH agent
            - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add -
            # Set up the SSH directory and authorized keys for secure connection
            - mkdir -p ~/.ssh
            - chmod 700 ~/.ssh
            - echo "$EC2_SSH_PUBLIC_KEY" > ~/.ssh/authorized_keys
            - chmod 600 ~/.ssh/authorized_keys
            # Clone the repository
            - git clone https://your-bitbucket-repository-url
            - cd your-project-directory
            # Install Node.js dependencies
            - npm install
            # Build the assets
            - npm run build
            # Install PHP dependencies
            - composer install --no-dev --optimize-autoloader
            # Sync files to EC2 instance using rsync (exclude unnecessary files)
            - rsync -avz --exclude=.git --exclude=node_modules ./ ubuntu@your-ec2-public-ip:/path/to/your/project
            # Run Laravel migrations and clear config cache on EC2
            - ssh -o StrictHostKeyChecking=no ubuntu@your-ec2-public-ip "cd /path/to/your/project && php artisan migrate && php artisan config:cache"

### Key Points:
1. **Branch-specific Trigger**:
– The `pipelines` section is configured to run only for the `main` branch. This ensures that changes will only be deployed when pushed to `main`.

2. **Steps Overview**:
– The `ssh-add` command is used to add the private SSH key (stored in the Bitbucket environment variable `SSH_PRIVATE_KEY`) to the SSH agent.
– The `rsync` command transfers the code to the EC2 instance, excluding unnecessary files like `.git` and `node_modules`.
– After transferring files, the pipeline SSHs into the EC2 instance and runs `php artisan migrate` and `php artisan config:cache` to handle database migrations and Laravel's config caching.

3. **Secure SSH Setup**:
– The private SSH key (`SSH_PRIVATE_KEY`) is used to authenticate the deployment. It’s stored securely in Bitbucket's environment variables (configured as a secure variable).
– The public key (`EC2_SSH_PUBLIC_KEY`) is added to the EC2 instance’s `~/.ssh/authorized_keys` to allow SSH access from Bitbucket Pipelines.

### Additional Notes:
– **Environment Variables**: Make sure that `SSH_PRIVATE_KEY` and `EC2_SSH_PUBLIC_KEY` are set up as environment variables in Bitbucket:
– `SSH_PRIVATE_KEY`: The private key you generated earlier.
– `EC2_SSH_PUBLIC_KEY`: The public key you added to your EC2 instance’s `authorized_keys` file.

– **Permissions**: Double-check that your EC2 instance’s `~/.ssh/authorized_keys` file has the correct permissions:

chmod 600 ~/.ssh/authorized_keys

– **Security**: Since this configuration deploys automatically from the `main` branch, make sure to only merge tested and stable code into the `main` branch to avoid deploying incomplete or broken changes.

By following this setup, your code will only be deployed to EC2 when pushed to the `main` branch. Let me know if you need further adjustments!

Here’s how it works:

### Scenario: Other Developer Pushes to `main`

1. **Developer Clones the Repository**: The developer clones the repository from Bitbucket to their local machine using:

git clone https://your-bitbucket-repository-url

2. **Developer Makes Changes Locally**: The developer makes changes to the codebase.

3. **Developer Pushes Changes to `main`**: Once the developer commits their changes locally, they push them to the `main` branch:

git push origin main

4. **Bitbucket Pipeline Triggers**: Since the pipeline is configured to trigger on changes to the `main` branch (as specified in the `bitbucket-pipelines.yml` file), the push from the developer will trigger the pipeline.

– Even though the changes came from a different developer's local system, **the pipeline is still triggered by the push to the `main` branch**, and the deployment process will start on the EC2 instance.

5. **Deployment Process Starts**: The steps you defined in the pipeline will execute, which typically include:
– Building the app
– Syncing the code to the EC2 instance
– Running migrations, clearing the config cache, etc.

### Key Points:

– **Bitbucket Pipelines is Repository-based**: The pipeline runs in the Bitbucket repository environment. It doesn’t matter who pushes the code; as long as the code is pushed to the branch specified in the pipeline (`main` in this case), it will trigger the pipeline.

– **Deployment Happens Automatically**: Whether you or another developer pushes the code, the pipeline will automatically deploy to your EC2 instance once the push to `main` occurs.

– **Ensure Proper Access Control**: If you're concerned about who can push to the `main` branch, consider setting up branch permissions in Bitbucket:
– You can restrict who can push directly to the `main` branch.
– You can require that all changes to `main` must come through a pull request, which can be reviewed and approved by others before merging.

This can help control which developers or collaborators can deploy code to production by ensuring that only trusted changes are pushed to `main`.

### Example of Setting Branch Permissions in Bitbucket:

To enforce more control over who can push to `main`, you can set branch permissions:
1. Go to **Repository Settings** → **Branch permissions**.
2. Click **Add permission** and select the `main` branch.
3. Set up permissions to restrict who can push, merge, or create branches, and whether pull requests are required.

### Example: Restricting Direct Push to `main`
– You can configure Bitbucket to only allow changes to `main` via pull requests, so no one can push directly to it. This ensures that code review processes are followed.

By doing this, you ensure that code is reviewed before it’s deployed, preventing unreviewed or potentially harmful changes from reaching your EC2 production environment.

Let me know if you need further details on setting up branch permissions or any other concerns!

Enter file in which to save the key (/root/.ssh/id_rsa):

is displayed when you run the `ssh-keygen` command to generate a new SSH key pair. The prompt is asking you where to save the private key (`id_rsa`) on your system.

### Explanation:
– **`/root/.ssh/id_rsa`** is the default file location where the private key will be saved if you press Enter without specifying a different path. This is typically the location for the root user’s SSH keys.

– **Private Key**: This file (`id_rsa`) is used for SSH authentication, and it should be kept private and secure. It will be used when connecting to remote systems like your EC2 instance.

– **Public Key**: The corresponding public key will be saved in the same directory as `id_rsa.pub`, and you can share it with remote servers or services (like your EC2 instance) to grant access.

### Options:
1. **Press Enter to Use the Default Path**:
If you want to save the SSH key in the default location, simply press **Enter**:

Enter file in which to save the key (/root/.ssh/id_rsa): [Press Enter]

2. **Specify a Different Path**:
If you don’t want to use the default location or are generating multiple keys for different purposes, you can type a different path and file name. For example:

Enter file in which to save the key (/root/.ssh/id_rsa): /home/user/.ssh/my_custom_key

This will save the private key to `/home/user/.ssh/my_custom_key` and the public key to `/home/user/.ssh/my_custom_key.pub`.

### After Key Generation:
Once you specify the location (or use the default), the key pair will be generated:
– The **private key** will be saved to the location you provided (e.g., `/root/.ssh/id_rsa`).
– The **public key** will be saved as `id_rsa.pub` (or your custom name with `.pub`).

You’ll then use the **public key** (`id_rsa.pub`) to add to your EC2 instance or other servers, and the **private key** (`id_rsa`) will be kept secure on your local machine for authentication.

Let me know if you need help with the key generation process!

Here’s how you can do it:

1. When the `ssh-keygen` command asks for the file in which to save the key:

Enter file in which to save the key (/root/.ssh/id_rsa):

2. Type the desired path, which in your case is `D:myprojectsid_rsa` (make sure to include the filename `id_rsa` at the end):

Enter file in which to save the key (D:myprojectsid_rsa):

3. Press **Enter**. This will save the private key to `D:myprojectsid_rsa` and the public key to `D:myprojectsid_rsa.pub`.

### Example Steps:
1. Open a terminal (e.g., Git Bash, Command Prompt, or PowerShell).
2. Run `ssh-keygen`:

ssh-keygen

3. When prompted to enter the file in which to save the key:

Enter file in which to save the key (/root/.ssh/id_rsa):

Type `D:myprojectsid_rsa` and press **Enter**.

### Note:
– If you're using Git Bash on Windows, paths may need to be written using forward slashes, like this:

/d/myprojects/id_rsa

– If you use PowerShell or Command Prompt, backslashes (“) are fine, like `D:myprojectsid_rsa`.

Let me know if you need further clarification or run into any issues!

### How to Save the SSH Key in WSL:

You can save the SSH key directly under `/mnt/d/myprojects` from within your WSL terminal.

When prompted by `ssh-keygen`:

Enter file in which to save the key (/root/.ssh/id_rsa):

You should enter the path to your desired location in the WSL environment, which would be:

/mnt/d/myprojects/id_rsa

This will save the private key as `id_rsa` in the `D:myprojects` directory on your Windows filesystem, and the public key will be saved as `id_rsa.pub` in the same location.

### Steps:

1. Run `ssh-keygen` in your WSL terminal:

ssh-keygen

2. When prompted for the file to save the key:

Enter file in which to save the key (/root/.ssh/id_rsa):

3. Type `/mnt/d/myprojects/id_rsa` and press **Enter**:

/mnt/d/myprojects/id_rsa

4. After that, you can use the private key (`id_rsa`) and public key (`id_rsa.pub`) in the `D:myprojects` directory in Windows.

### Summary:

– In **WSL**, you access the Windows filesystem through `/mnt/`.
– To save the SSH keys in `D:myprojects`, specify `/mnt/d/myprojects/id_rsa`.

This way, your keys will be saved in the `D:myprojects` directory on your Windows machine but accessible from within WSL.

Let me know if you need further assistance!

### What Happens If You Set a Passphrase:
– **Security**: If you set a passphrase, you'll need to enter it every time you use the private key (for example, when connecting to a server via SSH).
– **Convenience**: If you don’t set a passphrase, you can use the key without entering anything, making it more convenient, but less secure since anyone who gains access to the private key can use it without any further authentication.

### Do You Need to Set a Passphrase?
– **Optional**: It’s not required to set a passphrase, but it’s highly recommended for security purposes, especially for sensitive systems or production environments.
– **For convenience**: If you want to automate processes like deploying code or using the key in Bitbucket Pipelines, you can leave the passphrase empty to avoid manual entry each time the key is used.

### What to Do:
1. **If you want extra security**:
– Enter a passphrase (e.g., `MyStrongPassphrase123!`) and confirm it when prompted.
– You will need to type this passphrase each time the key is used.

2. **If you prefer convenience**:
– Simply press **Enter** when prompted for the passphrase to leave it empty. No passphrase will be set.

### Example Flow:

1. When prompted for the passphrase:

Enter passphrase (empty for no passphrase):

2. If you want a passphrase, enter it and press **Enter**.

3. If you don’t want a passphrase, simply press **Enter** twice (once for the passphrase and once for confirmation):

Enter passphrase (empty for no passphrase): [Press Enter]
   Enter same passphrase again: [Press Enter]

### Automation Considerations:
– **If you leave the passphrase empty**, you can use the SSH key without manual entry (this is common for automated deployments like in Bitbucket Pipelines).
– **If you set a passphrase**, you'll need to use `ssh-agent` to manage the passphrase securely, or provide the passphrase during the deployment process.

Let me know if you'd like more details on managing passphrases or automating SSH key usage!

### 1. **Access the EC2 Instance** (or the relevant server)

– If you're working with a remote server (like an EC2 instance), first, SSH into that server using the appropriate user:

ssh user@your-ec2-ip

Replace `user` with the username you use to SSH into the server (e.g., `ubuntu`, `ec2-user`, etc.), and replace `your-ec2-ip` with the EC2 instance's IP address.

### 2. **Navigate to the `~/.ssh` Directory**

Once logged into the server, navigate to the user's `.ssh` directory:

cd ~/.ssh

If you are checking for a specific user, you can switch to that user's home directory first (e.g., `cd /home/ubuntu/.ssh` for the `ubuntu` user).

### 3. **Check the `authorized_keys` File**

The public key(s) should be in the `authorized_keys` file within this directory. You can open it using a text editor or just display its contents:

– To **view** the file:

cat ~/.ssh/authorized_keys

This will print the content of the `authorized_keys` file to the terminal. The public key should appear as a long string starting with something like `ssh-rsa` or `ssh-ed25519`.

### 4. **Check for the Specific Public Key**

If you're looking for a specific public key, you can search for it in the `authorized_keys` file. Use `grep` to search for part of the key (such as the beginning of the key string):

grep "ssh-rsa" ~/.ssh/authorized_keys

This will search for any key starting with `ssh-rsa`. If you know the specific public key (or a portion of it), you can search for that exact string.

### 5. **Verify Correct Permissions**

Ensure the correct permissions are set for the `.ssh` directory and the `authorized_keys` file. The permissions should be as follows:

– `.ssh` directory: `700`
– `authorized_keys` file: `600`

You can check and correct the permissions like this:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

### Example:
Let’s say the public key you added is:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArD5JXfP5JHiCbEpiqBhT6R6GQb1S7oTkHCU4r1zXf0k27BojzlhkD4P0eF0KBeWe0Fh7uXkTnG27A0bHoTtAAkjRfTZq21pgjr0Up1qOQ8cGLt6Aiw8yBYY+/GQtH97o57p7bCJFCvEKNhOWM5os4FGxlz8p68FP9vG9WgS6kX+gAqIFfslQ== user@my-computer

To check if it’s in `authorized_keys`, you can run:

cat ~/.ssh/authorized_keys

Look for a line that begins with `ssh-rsa`, followed by the key string. If it appears, the public key is correctly added.

### Summary:

– SSH into the server.
– Navigate to `~/.ssh`.
– Use `cat ~/.ssh/authorized_keys` to view the file and check for the correct public key.
– Use `grep` to search for a specific key if needed.
– Ensure the correct file permissions.

Let me know if you encounter any issues or need further assistance!

### Explanation of the Public Key

This is the format of an SSH key entry in the `authorized_keys` file:

<options> <public-key> <comment>

In your case:
– **Options**:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user "ubuntu" rather than the user "root".';echo;sleep 10;exit 142"

These options are restrictions for the SSH session. For example:
– `no-port-forwarding`: Disables port forwarding.
– `no-agent-forwarding`: Disables SSH agent forwarding.
– `no-X11-forwarding`: Disables X11 forwarding.
– `command="…"`: Specifies that when the user connects with this key, the server will only run the specified command (in this case, an echo message and then exiting with a specific status code).

– **Public Key**:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDd4172WNuyblaOdDqsQtdKvvhEpXBJTZVAShJ44tXe2TSYC2fUAPSIP+bpmtTsmGqXDmWe/NO5rMqlrH1NT7BMPDY08XulxsCEOCQ6eauCGGwy+SJqoCIblZatL9JqvD0qt41xqk/BW837pls/Shb37HUdHAnx0sOgQvRns4sSMcXClAYX8FtIo7xC0TRI1I1GIbLqnb7aPBRaplAWW/vJblK0P+yXVbkGrDDrjX8Bt1TEiiA4MysW0c3wkslvXXvA2b7Yo+PRj7420TaH+KgHviGdOv6KouLexq/3oVJTBa69hPMo8O32m9t/W2gvE8ELMWn4ZDZm1BsQMXO4OElx

– **Comment**:

gotoapp

### How to Check if the Public Key is in `authorized_keys`

1. **SSH into the Server**: First, log into the server where the `authorized_keys` file is located.

ssh user@your-server-ip

Replace `user` with your actual username (e.g., `ubuntu`, `ec2-user`, etc.), and replace `your-server-ip` with your EC2 instance's IP or the server IP.

2. **Navigate to the `.ssh` Directory**: Once logged in, go to the `.ssh` directory of the user you want to check (e.g., `ubuntu`):

cd ~/.ssh

Or, if you are checking for another user, navigate to that user's home directory:

cd /home/ubuntu/.ssh

3. **View `authorized_keys`**: Display the contents of the `authorized_keys` file to check if the public key is added.

cat authorized_keys

4. **Search for the Key**: You can also use `grep` to search for part of the public key (e.g., `ssh-rsa` or the specific comment `gotoapp`).

grep "ssh-rsa" authorized_keys

Or search using the comment, if it was included in the key entry:

grep "gotoapp" authorized_keys

If the public key is present, it will be listed as a single line starting with `ssh-rsa`.

### Example Output

The line in `authorized_keys` will look something like this:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user "ubuntu" rather than the user "root".';echo;sleep 10;exit 142" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDd4172WNuyblaOdDqsQtdKvvhEpXBJTZVAShJ44tXe2TSYC2fUAPSIP+bpmtTsmGqXDmWe/NO5rMqlrH1NT7BMPDY08XulxsCEOCQ6eauCGGwy+SJqoCIblZatL9JqvD0qt41xqk/BW837pls/Shb37HUdHAnx0sOgQvRns4sSMcXClAYX8FtIo7xC0TRI1I1GIbLqnb7aPBRaplAWW/vJblK0P+yXVbkGrDDrjX8Bt1TEiiA4MysW0c3wkslvXXvA2b7Yo+PRj7420TaH+KgHviGdOv6KouLexq/3oVJTBa69hPMo8O32m9t/W2gvE8ELMWn4ZDZm1BsQMXO4OElx gotoapp

### Troubleshooting:

– **Key Not Found**: If you don't see the key listed, it means it hasn't been added yet, and you'll need to add the public key to the `authorized_keys` file manually.
– **Permissions Issue**: If the file or `.ssh` folder has incorrect permissions, SSH might ignore the key. Ensure the correct permissions are set:

chmod 700 ~/.ssh
  chmod 600 ~/.ssh/authorized_keys

Let me know if you need help with adding the key to `authorized_keys` or any other troubleshooting!

### Steps to Add the Public Key to `authorized_keys`

1. **Obtain the Public Key**: Ensure you have the correct public key (the one that starts with `ssh-rsa` or `ssh-ed25519`) that you want to add to the `authorized_keys` file.

Example public key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDd4172WNuyblaOdDqsQtdKvvhEpXBJTZVAShJ44tXe2TSYC2fUAPSIP+bpmtTsmGqXDmWe/NO5rMqlrH1NT7BMPDY08XulxsCEOCQ6eauCGGwy+SJqoCIblZatL9JqvD0qt41xqk/BW837pls/Shb37HUdHAnx0sOgQvRns4sSMcXClAYX8FtIo7xC0TRI1I1GIbLqnb7aPBRaplAWW/vJblK0P+yXVbkGrDDrjX8Bt1TEiiA4MysW0c3wkslvXXvA2b7Yo+PRj7420TaH+KgHviGdOv6KouLexq/3oVJTBa69hPMo8O32m9t/W2gvE8ELMWn4ZDZm1BsQMXO4OElx gotoapp

2. **SSH into the Server**: Log into your server where you want to add the key.

ssh user@your-server-ip

Replace `user` with the actual username (e.g., `ubuntu`, `ec2-user`, etc.), and `your-server-ip` with your EC2 instance's IP address or the server's IP address.

3. **Navigate to the `.ssh` Directory**: Once logged in, go to the `.ssh` directory in the user's home directory.

cd ~/.ssh

Or for a specific user, you might need to go to `/home/ubuntu/.ssh` or `/home/ec2-user/.ssh`, etc.

4. **Open or Create `authorized_keys`**: If the `authorized_keys` file doesn't exist, you can create it. Open the file in a text editor (e.g., `nano` or `vi`).

nano authorized_keys

If the file doesn't exist, this will create a new one.

5. **Add the Public Key**: Copy the entire public key (from `ssh-rsa` to the end of the key) and paste it into the `authorized_keys` file.

– **Paste the key**: Right-click or use `Ctrl+Shift+V` (depending on your terminal) to paste the public key.
– Ensure the key is on a single line, and there are no extra spaces or line breaks.

Example:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user "ubuntu" rather than the user "root".';echo;sleep 10;exit 142" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDd4172WNuyblaOdDqsQtdKvvhEpXBJTZVAShJ44tXe2TSYC2fUAPSIP+bpmtTsmGqXDmWe/NO5rMqlrH1NT7BMPDY08XulxsCEOCQ6eauCGGwy+SJqoCIblZatL9JqvD0qt41xqk/BW837pls/Shb37HUdHAnx0sOgQvRns4sSMcXClAYX8FtIo7xC0TRI1I1GIbLqnb7aPBRaplAWW/vJblK0P+yXVbkGrDDrjX8Bt1TEiiA4MysW0c3wkslvXXvA2b7Yo+PRj7420TaH+KgHviGdOv6KouLexq/3oVJTBa69hPMo8O32m9t/W2gvE8ELMWn4ZDZm1BsQMXO4OElx gotoapp

6. **Save and Exit**: After pasting the key, save and exit the editor:
– In `nano`: Press `Ctrl+O` to save, then `Ctrl+X` to exit.
– In `vi`: Press `Esc`, then type `:wq` and press Enter.

7. **Set Correct Permissions**: Make sure the `.ssh` directory and the `authorized_keys` file have the correct permissions.

chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys

8. **Test the SSH Key**: After adding the key, you should test it by trying to SSH into the server using the private key associated with the public key you just added.

ssh -i /path/to/private_key user@your-server-ip

If the key was added correctly and permissions are set properly, you should be able to log in without entering a password.

—

### Summary:

– SSH into the server.
– Navigate to `~/.ssh` and open or create the `authorized_keys` file.
– Paste the public key into `authorized_keys`.
– Set correct permissions with `chmod`.
– Test by SSH'ing into the server using the private key.

Let me know if you encounter any issues!

### 1. **Obtain the Private Key**
Make sure you have your private SSH key ready. This is the key corresponding to the public key that you added to the `~/.ssh/authorized_keys` file on your EC2 server.

For example, your private key might look like this:

-----BEGIN OPENSSH PRIVATE KEY-----
<key content>
-----END OPENSSH PRIVATE KEY-----

### 2. **Add the Private Key as a Secure Environment Variable**
Bitbucket Pipelines allows you to securely store environment variables that can be accessed during the build process. You will store the private SSH key in Bitbucket's environment variables so that it can be used by your pipeline.

Follow these steps to add the private key:

#### 1.1. Go to Your Bitbucket Repository
– Navigate to your repository in Bitbucket.

#### 1.2. Open Repository Settings
– In the left sidebar, click on **Repository settings**.

#### 1.3. Add the Environment Variable
– Under **Pipelines**, click on **Repository variables**.
– Click on **Add variable**.
– Add a variable with the following details:
– **Name**: `SSH_PRIVATE_KEY`
– **Value**: Paste the entire private key into the value field. Make sure to preserve the line breaks, such as the lines starting with `—–BEGIN OPENSSH PRIVATE KEY—–` and ending with `—–END OPENSSH PRIVATE KEY—–`.
– **Secured**: Ensure the "Secured" checkbox is checked to keep the private key hidden.

After you add the variable, it will be securely stored and encrypted.

### 3. **Update Your Bitbucket Pipeline to Use the Private Key**

Once the private key is stored in the environment variable `SSH_PRIVATE_KEY`, you can modify your Bitbucket pipeline configuration to use it during the deployment process.

In your `bitbucket-pipelines.yml`, use the following steps to inject the private key into the SSH agent and deploy:

#### 3.1. Edit `bitbucket-pipelines.yml`
Here’s how you can modify the pipeline configuration:

image: atlassian/default-image:3

pipelines:
  default:
    - step:
        name: Deploy to EC2
        caches:
          - docker
        script:
          - apt-get update && apt-get install -y openssh-client
          - mkdir -p ~/.ssh
          - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
          - chmod 600 ~/.ssh/id_rsa
          - ssh-keyscan -H your-ec2-ip >> ~/.ssh/known_hosts
          - ssh -o StrictHostKeyChecking=no user@your-ec2-ip "your-deploy-script.sh"

#### Explanation:
– **Install SSH Client**: First, we install the `openssh-client` on the pipeline's build environment.
– **Set Up SSH Key**: The private key is retrieved from the environment variable `$SSH_PRIVATE_KEY` and saved to `~/.ssh/id_rsa`. We set the correct permissions (`chmod 600`).
– **SSH Known Hosts**: We use `ssh-keyscan` to add the EC2 server's fingerprint to the `~/.ssh/known_hosts` file to avoid SSH warnings.
– **Deploy via SSH**: Finally, we use SSH to log into the EC2 instance and execute the deployment script.

### 4. **Test the Pipeline**

After configuring the pipeline, push your changes to the Bitbucket repository, and trigger the pipeline to test if the private key is correctly used for deploying to the EC2 instance.

### Troubleshooting Tips:
– Ensure that the private key in the environment variable is correctly formatted, with no extra spaces or line breaks.
– If the pipeline fails to authenticate, double-check that the public key is properly added to `~/.ssh/authorized_keys` on the EC2 instance.
– Ensure that the private key is properly protected by setting the "Secured" checkbox to prevent exposure in logs.

Let me know if you need further help with this!

### 1. **Use an Existing Private Key**

If you already have an SSH key pair (i.e., private and public keys), the private key is typically stored in the `.ssh` folder on your local machine. The private key file usually has the name `id_rsa` or `id_ed25519`, depending on the type of key you created.

– On **Linux/macOS** or **WSL** (Windows Subsystem for Linux), you can find the private key in:

~/.ssh/id_rsa

– On **Windows**, using WSL, it would be located in:

/mnt/c/Users/YourUsername/.ssh/id_rsa

– On **Windows (using native SSH clients like PuTTY)**, the private key might be a `.ppk` file.

To view the private key:
– Open the file in a text editor (e.g., `nano`, `vi`, or just a text editor).

cat ~/.ssh/id_rsa

– **Important**: When you view the private key, **do not share it**. The private key should remain confidential and should never be exposed publicly.

The private key content will look something like this:

-----BEGIN OPENSSH PRIVATE KEY-----
<key content>
-----END OPENSSH PRIVATE KEY-----

### 2. **Generate a New SSH Key Pair**

If you don't have an SSH key pair yet, you can generate a new one. Here’s how to generate a new key pair:

#### 2.1. Open a terminal or WSL (for Windows users)
– On **Linux/macOS** or **WSL**, you can generate a new SSH key pair by running the following command:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

This will generate a 4096-bit RSA key pair with the comment `"your_email@example.com"`.

#### 2.2. Follow the Prompts
– **File location**: The tool will ask where to save the key. By default, it will save to `~/.ssh/id_rsa` (or `/mnt/c/Users/YourUsername/.ssh/id_rsa` on Windows WSL). You can press Enter to accept the default location or specify a different path.

– **Passphrase**: You’ll be asked to enter a passphrase. You can either leave it empty (press Enter) or set a passphrase for added security.

#### 2.3. View the Generated Private Key
After generating the key pair, you can find your private key in the location you chose (or by default in `~/.ssh/id_rsa`). Use the `cat` command to display the private key:

cat ~/.ssh/id_rsa

The private key will look like this:

-----BEGIN OPENSSH PRIVATE KEY-----
<key content>
-----END OPENSSH PRIVATE KEY-----

### 3. **Use the Private Key in Bitbucket Pipelines**

Once you have the private key, you can copy its content and use it in your Bitbucket pipeline as described earlier:

1. **Copy the private key**: Copy everything, including the `—–BEGIN OPENSSH PRIVATE KEY—–` and `—–END OPENSSH PRIVATE KEY—–` lines.

2. **Add it to Bitbucket Pipelines**:
– Go to **Repository settings** > **Repository variables** in Bitbucket.
– Add a new variable with the name `SSH_PRIVATE_KEY`.
– Paste the private key content into the value field and make sure to mark it as "Secured."

—

### Important Notes:
– **Never expose your private key**. Keep it secure and ensure that it is not accidentally shared.
– **Private key is sensitive**: Be cautious when copying the private key. Only share it with trusted systems.

Let me know if you need further assistance!

### Assumptions:
– The EC2 instance is accessible via SSH.
– The username is `ubuntu` (common for EC2 instances created with Ubuntu).
– Your project is located in `/var/www/shareyourthoughts` on the EC2 instance.
– You will use SSH to deploy the code and run `npm run build` remotely.

### Step 1: **Add the SSH Private Key as a Secure Environment Variable**
Follow the steps from earlier to securely store the private key in Bitbucket Pipelines.

– **Name**: `SSH_PRIVATE_KEY`
– **Value**: Paste the private key (from the key you generated earlier) into the environment variable field.

### Step 2: **Set Up the Bitbucket Pipeline Configuration**

Here’s an updated example of a `bitbucket-pipelines.yml` file for your use case, where the pipeline will:

1. Push the code to the EC2 server via SSH.
2. Run `npm run build` in the project folder `/var/www/shareyourthoughts`.

image: atlassian/default-image:3  # Choose an image with Node.js, such as the default image

pipelines:
  default:
    - step:
        name: Deploy and Build on EC2
        caches:
          - docker
        script:
          # Install SSH client
          - apt-get update && apt-get install -y openssh-client

          # Create the SSH folder
          - mkdir -p ~/.ssh

          # Add the private key to the SSH config
          - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
          
          # Secure the private key
          - chmod 600 ~/.ssh/id_rsa
          
          # Add EC2's SSH fingerprint to known hosts
          - ssh-keyscan -H ec2-16-170-254-93.eu-north-1.compute.amazonaws.com >> ~/.ssh/known_hosts

          # SSH into EC2 and navigate to the project folder
          - ssh -o StrictHostKeyChecking=no ubuntu@ec2-16-170-254-93.eu-north-1.compute.amazonaws.com "
              cd /var/www/shareyourthoughts &&
              git pull origin main &&  # Ensure the latest code is pulled from Bitbucket
              npm install &&          # Install dependencies
              npm run build"          # Run the build process

### Breakdown of the Steps in `bitbucket-pipelines.yml`:

1. **Install SSH Client**: The `openssh-client` is installed in the pipeline environment, so you can use `ssh` commands.

2. **Set Up the Private Key**:
– The `SSH_PRIVATE_KEY` environment variable is retrieved and saved into `~/.ssh/id_rsa`.
– The file permissions are set to `600` to ensure the key is secure.

3. **Add EC2 to Known Hosts**:
– `ssh-keyscan` is used to add the EC2 instance's public SSH key to the `known_hosts` file. This prevents SSH warnings when connecting to the EC2 instance.

4. **SSH into the EC2 Instance**:
– The pipeline connects to the EC2 instance with the `ubuntu` user.
– It then navigates to the `/var/www/shareyourthoughts` directory.
– The pipeline pulls the latest changes from the `main` branch of your Bitbucket repository using `git pull origin main`.
– After that, it installs any missing dependencies with `npm install` and runs the `npm run build` command to build the project.

### Step 3: **Test the Pipeline**

– **Push to the `main` Branch**: After updating your `bitbucket-pipelines.yml`, push the changes to the `main` branch of your Bitbucket repository.

– **Check the Pipeline Logs**: Once the code is pushed, go to **Pipelines** in Bitbucket to monitor the deployment process. If everything is set up correctly, the pipeline should automatically SSH into the EC2 instance, pull the latest code, and run the `npm run build` command.

### Troubleshooting:
– Ensure that the private key is correct and properly formatted.
– Ensure the EC2 instance has SSH access enabled and that the public key corresponding to your private key is added to the `~/.ssh/authorized_keys` on the EC2 instance.
– Check for any errors in the pipeline logs and adjust the configuration as needed.

Let me know if you run into any issues!

### Solution: Ignore `node_modules` and `vendor` from Watching

You can use the `server.watch` option in your `vite.config.js` to exclude certain directories from being watched. Here's how you can configure it:

#### Example `vite.config.js`

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
  plugins: [
    laravel({
      input: ['resources/js/app.js'],
      refresh: true,
    }),
    vue(),
  ],
  server: {
    watch: {
      ignored: [
        '**/node_modules/**',
        '**/vendor/**'
      ],
    },
  },
});

### Explanation:
– **`server.watch.ignored`**: This option uses glob patterns to exclude files or directories from being watched by Vite.
– `**/node_modules/**` ignores everything inside the `node_modules` folder.
– `**/vendor/**` ignores everything inside the `vendor` folder.

### Additional Tips:
1. **Improve Performance with More Exclusions**:
– If you are using Docker, you might also want to ignore the `.git`, `.idea`, and other unnecessary folders to speed up Vite even further.

server: {
       watch: {
         ignored: [
           '**/node_modules/**',
           '**/vendor/**',
           '**/.git/**',
           '**/.idea/**',
         ],
       },
     },

2. **Check for Docker-Specific Configurations**:
– If you're running Vite in a Docker environment, ensure you have proper volume configurations to avoid performance bottlenecks. You can set `CHOKIDAR_USEPOLLING=true` if you encounter file change detection issues inside Docker, but use it only when necessary as it can consume more CPU resources.

3. **Restart Vite**:
– After updating `vite.config.js`, make sure to restart your Vite server for the changes to take effect.

This configuration should help you avoid unnecessary file watching, thus improving the performance of your development environment.

### Solution 1: **Pull with Rebase (Recommended)**

To integrate remote changes into your local branch without creating extra merge commits, you can use `git pull –rebase`:

git pull --rebase origin master

Then, push your changes:

git push origin master

**Explanation**:
– `git pull –rebase`: This pulls the changes from the remote branch and applies your local commits on top of the pulled commits. It keeps a cleaner commit history compared to a regular `git pull`.
– `git push`: After the rebase, your branch will be up to date with the remote, and you can push your changes without issues.

### Solution 2: **Force Push (Use with Caution)**

If you are sure that your local changes should override the remote changes, you can force push. However, be cautious as this will overwrite the remote branch history:

git push --force origin master

**Explanation**:
– `git push –force`: This command forces your local changes to overwrite the remote branch. Use this only if you're sure that the remote changes can be discarded.

### Solution 3: **Merge Remote Changes Locally**

If you want to merge the changes from the remote branch into your local branch, follow these steps:

1. **Pull the latest changes from the remote branch**:

git pull origin master

2. **Resolve any merge conflicts if prompted**.
3. **Push your changes**:

git push origin master

### Solution 4: **If You Don't Want to Keep Remote Changes**

If you don't care about the changes on the remote and want your local changes to overwrite everything, you can reset your branch to match the remote branch and then force push:

git fetch origin
git reset --hard origin/master
git push --force origin master

**Explanation**:
– `git fetch origin`: Fetches the latest changes from the remote without merging.
– `git reset –hard origin/master`: Resets your local branch to match the remote branch, discarding any local changes.
– `git push –force`: Pushes your local branch to the remote, overwriting it.

### Quick Summary of Commands

| Scenario | Command |
|———————————–|———————————————-|
| Sync and rebase | `git pull –rebase origin master` |
| Merge remote changes | `git pull origin master` |
| Overwrite remote branch (force) | `git push –force origin master` |
| Reset to remote state and push | `git fetch origin && git reset –hard origin/master && git push –force origin master` |

Choose the solution that best fits your workflow and collaboration needs.

### Solution 1: **Pull with Rebase (Recommended)**

This is the recommended approach as it keeps the commit history clean by applying your changes on top of the latest changes from the remote branch.

1. **Pull the latest changes from the remote branch with rebase**:

git pull --rebase origin master

2. **Push your changes to the remote branch**:

git push origin master

**Explanation**:
– `git pull –rebase origin master`: This fetches the remote changes and re-applies your local commits on top of the fetched changes.
– `git push origin master`: Pushes your rebased changes to the remote repository.

If there are conflicts during the rebase, Git will prompt you to resolve them. After resolving, run:

git rebase --continue

### Solution 2: **Merge Remote Changes**

If you prefer to merge the remote changes into your local branch, you can use:

1. **Pull the latest changes from the remote branch**:

git pull origin master

2. **Push your changes to the remote branch**:

git push origin master

**Explanation**:
– `git pull origin master`: Merges the remote changes into your local branch.
– If there are merge conflicts, resolve them, then commit the changes.

### Solution 3: **Force Push (Use with Caution)**

If you are certain that your local changes should overwrite the remote changes, you can force push. However, this is risky as it will overwrite the remote history, potentially affecting other collaborators.

git push --force origin master

**Explanation**:
– `git push –force`: Pushes your local branch, forcefully overwriting the remote branch.

### Solution 4: **Hard Reset to Remote Branch (Destructive)**

If you want to discard your local changes and fully sync with the remote branch, you can do the following:

1. **Fetch the latest changes**:

git fetch origin

2. **Reset your local branch to match the remote**:

git reset --hard origin/master

3. **Push your changes (if needed)**:

git push origin master

**Explanation**:
– `git reset –hard origin/master`: Discards all local commits and resets to the state of the remote `master` branch.
– Be careful with this approach, as it will delete all your local changes.

### Quick Summary of Commands

| Scenario | Command |
|———————————–|———————————————-|
| Sync and rebase | `git pull –rebase origin master` |
| Merge remote changes | `git pull origin master` |
| Overwrite remote branch (force) | `git push –force origin master` |
| Reset to remote state | `git fetch origin && git reset –hard origin/master` |

Choose the method that best fits your situation. If you're collaborating with others, it's generally better to avoid force pushing unless absolutely necessary.

### Option 1: **Commit Your Changes**

If you want to keep the changes you made, you can stage and commit them:

1. **Stage your changes**:

git add .

2. **Commit your changes**:

git commit -m "Your commit message"

3. **Pull with rebase**:

git pull --rebase origin master

4. **Push your changes**:

git push origin master

### Option 2: **Stash Your Changes (Recommended if You're Not Ready to Commit)**

If you're not ready to commit your changes, you can temporarily save them using `git stash`:

1. **Stash your changes**:

git stash save "WIP: save changes"

2. **Pull with rebase**:

git pull --rebase origin master

3. **Apply your stashed changes**:

git stash pop

4. **Resolve any conflicts if they appear**, then add and commit the changes as needed.

5. **Push your changes**:

git push origin master

### Option 3: **Discard Unstaged Changes (Destructive)**

If you don't need the local changes and want to discard them, you can reset your working directory:

1. **Discard all local changes**:

git reset --hard

2. **Pull with rebase**:

git pull --rebase origin master

3. **Push your changes** (if needed):

git push origin master

### Explanation

– **`git add .`**: Stages all modified and new files.
– **`git commit -m`**: Commits the staged changes with a message.
– **`git stash save`**: Temporarily saves your local changes so you can pull or switch branches without losing them.
– **`git stash pop`**: Restores the stashed changes.
– **`git reset –hard`**: Discards all local changes, resetting the branch to its last commit.

Choose the solution that best fits your current workflow and whether you want to keep or discard your local changes.

### 1. **Check if Vite Server is Running**

First, make sure that the Vite server is actually running on the EC2 instance:

npm run dev

The output should indicate that Vite is serving on `http://localhost:5173` or `http://0.0.0.0:5173`.

### 2. **Update Vite Configuration**

Ensure that Vite is set up to listen on all IP addresses, not just `localhost`. In your `vite.config.js` file, configure the server like this:

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
  plugins: [vue()],
  server: {
    host: '0.0.0.0', // Allow access from any IP
    port: 5173,
    watch: {
      usePolling: true,
    },
  },
});

– **`host: '0.0.0.0'`** allows external access to your Vite server.
– **`usePolling: true`** is useful if you're running Vite inside a Docker container or WSL.

### 3. **Open Port 5173 in AWS Security Group**

You need to allow inbound traffic on port `5173` in your EC2 instance's security group:

1. **Log in to your AWS Management Console**.
2. **Navigate to EC2 Dashboard** > **Instances**.
3. Select your instance (`ec2-16-170-254-93.eu-north-1.compute.amazonaws.com`).
4. Click on the **Security** tab, then click on the **Security Groups** link.
5. In the **Inbound rules** section, click **Edit inbound rules**.
6. Click **Add rule**:
– **Type**: Custom TCP
– **Port Range**: 5173
– **Source**: `0.0.0.0/0` (or restrict to your IP address for security)
7. Click **Save rules**.

### 4. **Check EC2 Instance Firewall (UFW)**

If you're using **UFW (Uncomplicated Firewall)** on your Ubuntu EC2 instance, make sure port `5173` is allowed:

sudo ufw allow 5173
sudo ufw reload

You can check the status of UFW with:

sudo ufw status

### 5. **Check Vite Server Logs**

If it’s still not working, check the logs for any errors:

npm run dev

### 6. **Access the Server Using Public IP**

Instead of using the hostname, try using the public IP directly:

http://16.170.254.93:5173

This helps rule out DNS issues.

### Summary

– Ensure Vite is listening on `0.0.0.0`.
– Allow inbound traffic on port `5173` in your AWS security group.
– Make sure any firewalls on the EC2 instance itself are not blocking the port.
– Verify that the Vite server is up and running.

These steps should help you resolve the timeout issue. Let me know if you encounter any further issues!

### Step 1: Update `vite.config.js`

Open your `vite.config.js` file and update the server configuration:

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
  plugins: [vue()],
  server: {
    host: '0.0.0.0', // Allow access from any IP address
    port: 3000,      // Change the port number here
    watch: {
      usePolling: true,
    },
  },
});

In this example, I've changed the port to `3000`.

### Step 2: Open the New Port in AWS Security Group

Since you've changed the port to `3000`, you need to allow inbound traffic on this new port in your AWS EC2 security group.

1. Go to the **AWS Management Console**.
2. Navigate to **EC2 Dashboard** > **Instances**.
3. Select your instance (`ec2-16-170-254-93.eu-north-1.compute.amazonaws.com`).
4. Click on the **Security** tab and then **Security Groups**.
5. Click on the **Inbound rules** section and click **Edit inbound rules**.
6. Click **Add rule**:
– **Type**: Custom TCP
– **Port Range**: 3000 (or your new port)
– **Source**: `0.0.0.0/0` (or restrict to your IP for security)
7. Click **Save rules**.

### Step 3: Restart Vite Server

Now, restart your Vite server with the updated configuration:

npm run dev

### Step 4: Access the Server

You can now access your Vite development server on the new port:

http://ec2-16-170-254-93.eu-north-1.compute.amazonaws.com:3000

or using the public IP:

http://16.170.254.93:3000

### Optional: Allow the New Port in UFW (if enabled)

If you’re using **UFW** on your EC2 instance, make sure to allow the new port:

sudo ufw allow 3000
sudo ufw reload

This will ensure your EC2 instance can accept connections on the new port.

export default defineConfig({
cacheDir: './node_modules/.vite',
plugins: [
laravel({
input: ['resources/js/app.js', 'resources/js/app-backend.js'],
refresh: true,
}),
vue({
template: {
transformAssetUrls: {
base: null,
includeAbsolute: false,
},
},
}),
],
server: {
host: '0.0.0.0', // Bind to all network interfaces, allowing external access
port: 3000, // Ensure this port is open in your AWS security group
hmr: {
host: 'ec2-16-170-254-93.eu-north-1.compute.amazonaws.com', // Your EC2 instance's public DNS
port: 3000,
},
watch: {
usePolling: true,

Here’s an improved version of your `vite.config.js`:

### Updated `vite.config.js`

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
  cacheDir: './node_modules/.vite',
  plugins: [
    laravel({
      input: ['resources/js/app.js', 'resources/js/app-backend.js'],
      refresh: true,
    }),
    vue({
      template: {
        transformAssetUrls: {
          base: null,
          includeAbsolute: false,
        },
      },
    }),
  ],
  server: {
    host: '0.0.0.0', // Bind to all network interfaces, allowing external access
    port: 3000, // Make sure this port is open in your AWS security group
    strictPort: true, // Fail if the port is already in use
    hmr: {
      protocol: 'ws', // Use WebSocket for HMR
      host: 'ec2-16-170-254-93.eu-north-1.compute.amazonaws.com', // Your EC2 instance's public DNS
      port: 3000,
    },
    watch: {
      usePolling: true,
    },
  },
});

### Explanation of Changes:

1. **`strictPort: true`**:
– Ensures that if port `3000` is already in use, Vite will fail to start instead of choosing a different port. This is useful for consistency when deploying.

2. **`protocol: 'ws'` in HMR**:
– Explicitly uses WebSocket protocol for Hot Module Replacement (HMR). This can help in environments where secure websockets (`wss`) are not required.

### Additional Steps:

#### 1. **Ensure Port 3000 is Open in AWS Security Group**:
– Go to your AWS Management Console > EC2 > Security Groups.
– Select the security group attached to your instance.
– Click **Edit Inbound Rules** and add:
– **Type**: Custom TCP
– **Port Range**: 3000
– **Source**: `0.0.0.0/0` (or restrict to your specific IP for security)

#### 2. **Check UFW (if applicable)**:
If your Ubuntu instance uses **UFW (Uncomplicated Firewall)**, make sure port `3000` is allowed:

sudo ufw allow 3000
sudo ufw reload

#### 3. **Restart Vite Server**:

npm run dev

#### 4. **Access the Vite Server**:
– You can now access your Vite server at:

http://ec2-16-170-254-93.eu-north-1.compute.amazonaws.com:3000

– Ensure your browser can access the port and that any browser firewalls are not blocking it.

### Debugging Tips:

– If you still face issues, try checking if the port is open using:

sudo netstat -tulnp | grep 3000

– Ensure no other processes are using port `3000`.

These adjustments should ensure that your Vite server works seamlessly on your AWS EC2 setup. Let me know if you encounter any further issues!

### Steps to Add Multiple Inbound Rules (Without Deleting Existing Rules)

1. **Log in to the AWS Management Console**.
2. Go to **EC2 Dashboard** > **Instances**.
3. Select your EC2 instance (`ec2-16-170-254-93.eu-north-1.compute.amazonaws.com`).
4. Click on the **Security** tab, then click on the **Security Groups** link associated with your instance.
5. In the **Inbound rules** section, click **Edit inbound rules**.

#### Add the Following Rules:

– **Rule for SSH (Port 22)**:
– **Type**: SSH
– **Protocol**: TCP
– **Port Range**: `22`
– **Source**: `0.0.0.0/0` (or restrict to your specific IP, e.g., `203.0.113.0/24` for better security)

– **Rule for Vite Server (Port 3000)**:
– **Type**: Custom TCP
– **Protocol**: TCP
– **Port Range**: `3000`
– **Source**: `0.0.0.0/0` (or restrict to your specific IP if needed)

6. Click **Save rules**.

### Important Notes:

– **Never delete the SSH rule (port 22)** unless you're using a different method for accessing your server (like AWS Systems Manager Session Manager).
– **Restricting access**: For better security, replace `0.0.0.0/0` with your specific IP address or CIDR block, e.g., `203.0.113.0/32`, to prevent unauthorized access.

### Verifying the Security Group Configuration:

You can verify the current inbound rules via the AWS Management Console or using the AWS CLI:

aws ec2 describe-security-groups --group-ids <your-security-group-id>

### Example of Expected Output:

Inbound Rules:
- Port 22: SSH from 0.0.0.0/0
- Port 3000: Custom TCP from 0.0.0.0/0

### Testing SSH and Vite Server Access

– **SSH Access**:

ssh ubuntu@ec2-16-170-254-93.eu-north-1.compute.amazonaws.com

– **Access Vite Server**:

http://ec2-16-170-254-93.eu-north-1.compute.amazonaws.com:3000

By ensuring both rules are active, you can avoid losing SSH access while running your Vite development server.

LARAVEL v11.26.0 plugin v1.0.6

➜ APP_URL: http://ec2-16-170-254-93.eu-north-1.compute.amazonaws.com
still showing 5173

### Step 1: Clear Caches and Restart Vite

Before starting Vite again, ensure you've cleared any cache that might be causing the issue.

#### 1.1. Delete the `.vite` cache directory:

rm -rf node_modules/.vite

#### 1.2. Delete the `dist` folder if it exists:

rm -rf dist

#### 1.3. Clear Node Modules Cache (Optional):

rm -rf node_modules
npm cache clean --force
npm install

### Step 2: Update `vite.config.js`

Make sure your `vite.config.js` is set to use the correct port (`3000`), and it is properly configured to listen on all network interfaces:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
  cacheDir: './node_modules/.vite',
  plugins: [
    laravel({
      input: ['resources/js/app.js', 'resources/js/app-backend.js'],
      refresh: true,
    }),
    vue({
      template: {
        transformAssetUrls: {
          base: null,
          includeAbsolute: false,
        },
      },
    }),
  ],
  server: {
    host: '0.0.0.0', // Listen on all network interfaces
    port: 3000, // Change to your desired port
    strictPort: true, // Fail if the port is already in use
    hmr: {
      host: 'ec2-16-170-254-93.eu-north-1.compute.amazonaws.com', // Your EC2 instance's public DNS
      protocol: 'ws',
      port: 3000,
    },
    watch: {
      usePolling: true,
    },
  },
});

### Step 3: Restart the Vite Server

Make sure you kill any existing Vite server process before starting it again.

#### 3.1. Kill existing Vite process:

If you started Vite using `npm run dev`, you can stop it with:

Ctrl + C

Or find the process using port `5173` and kill it:

sudo lsof -i :5173

Then kill the process ID (PID) from the output:

sudo kill -9 <PID>

#### 3.2. Restart Vite:

npm run dev

### Step 4: Verify the Vite Server

After restarting, it should show something like this:

➜  Local:   http://localhost:3000/
➜  Network: http://172.31.37.12:3000/
➜  press h + enter to show help

### Step 5: Update Your Security Group in AWS (If Not Already Done)

Make sure the AWS security group attached to your EC2 instance allows inbound traffic on port `3000`.

1. **Go to AWS Management Console** > **EC2** > **Instances**.
2. Select your instance and go to **Security Groups**.
3. **Edit Inbound Rules**:
– **Type**: Custom TCP
– **Port Range**: `3000`
– **Source**: `0.0.0.0/0` (or your specific IP for security)

### Step 6: Access Your Application

Now, try accessing your Vite server at:

http://ec2-16-170-254-93.eu-north-1.compute.amazonaws.com:3000

If everything is set up correctly, your application should now be available on port `3000`.