# .env file

## 📄 What is a `.env` file?

A **`.env` file** is a simple text file used to store **environment variables**. It is the industry standard for keeping sensitive information, such as API tokens, database passwords, and secret keys, separate from your application's source code.

By using a `.env` file, you ensure that your secrets are not hardcoded, making your application more secure and easier to configure across different environments (development, staging, production).

***

## 🛠️ How it Works

The file consists of **Key-Value pairs**, where each line represents a variable.

#### Syntax Rules:

* **Format:** `KEY=VALUE`
* **No Spaces:** Do not put spaces around the `=` sign.
* **Quotes:** Values with spaces should be wrapped in double quotes (`"`).
* **Comments:** Use `#` to add comments.

{% code title=".env" %}

```
# This is a comment
DISCORD_TOKEN=your_token_here
DATABASE_URL="mongodb+srv://user:pass@cluster.mongodb.net/myFirstDatabase"
PORT=8080
```

{% endcode %}

***

## 🔒 Security Best Practices

<details>

<summary>Never Commit to Git</summary>

Your `.env` file contains sensitive data. **Never** upload it to GitHub, GitLab, or any public repository. If you do, anyone with access to the repository can steal your credentials.

</details>

<details>

<summary>Use <code>.gitignore</code></summary>

To prevent accidental uploads, add `.env` to your `.gitignore` file:

{% code title=".gitignore" %}

```
.env
```

{% endcode %}

</details>

<details>

<summary>Create a Template</summary>

Since you won't be sharing your `.env` file, it's helpful to provide a `.env.example` file with the keys but no real values. This helps other developers (or your future self) know which variables are required.

</details>

<details>

<summary>Avoid Hardcoding</summary>

Hardcoding sensitive information directly into your source code is a major security risk. When you "hardcode" a secret, it becomes a permanent part of your codebase, even if you delete it later, it remains visible in your Git history.

**Why you should avoid it:**

* **Security Exposure:** Anyone with access to your code (or your repository history) can see your secrets.
* **Lack of Flexibility:** You would need to modify and redeploy your code every time you want to change a token or database URL.
* **Accidental Leaks:** It is very easy to accidentally push hardcoded secrets to public platforms like GitHub.

Instead, always reference environment variables. This keeps your secrets in a separate file (`.env`) that is never committed to version control, ensuring that your code remains clean and secure.

**Example:**

* **❌ Bad Practice:** `const token = "MTIzNDU2Nzg5MDEyMzQ1Njc4.GbX123.abcde...";`
* **✅ Good Practice:** `const token = process.env.DISCORD_TOKEN;`

</details>

***

## ☁️ Usage on Discloud

On Discloud, the `.env` file is the primary way to manage your application's secrets.

* **Placement:** Your environment files **must** be located in the **root of your project**, alongside your `discloud.config`.
* **Loading:** While `.env` is the default name for most libraries, Discloud allows you to use custom filenames (e.g., `.env.production`) as long as your application code is configured to load them.

***

## 📝 Language Examples

Here is how you can access environment variables in different programming languages:

{% tabs %}
{% tab title="Node.js" %}
In Node.js, you typically use the `dotenv` package. By default, it looks for `.env`, but you can specify a path.

```javascript
// Default (.env)
require('dotenv').config();

const token = process.env.DISCORD_TOKEN;
```

{% endtab %}

{% tab title="Python" %}
In Python, you can use `python-dotenv`.

```python
from dotenv import load_dotenv

# Default (.env)
load_dotenv()

token = os.getenv("DISCORD_TOKEN")
```

{% endtab %}

{% tab title="Java" %}
In Java, you can use `System.getenv()`.

```java
public class Main {
    public static void main(String[] args) {
        String token = System.getenv("DISCORD_TOKEN");
        System.out.println("Token: " + token);
    }
}
```

{% endtab %}
{% endtabs %}