# Hosting a Website/API from behind NAT

> Octelium documentation. Canonical page: <https://octelium.com/docs/octelium/latest/management/guide/service/homelab/website-api-hosting-nat>.

> **Note:**
>
> For a more comprehensive example that provides you a guide to use Octelium as an ngrok/Cloudflare Tunnel self-hosted alternative, check out the guide [here](https://octelium.com/docs/octelium/latest/management/guide/service/http/open-source-self-hosted-ngrok-alternative.md).

Octelium enables you to seamlessly host and serve your websites and HTTP APIs from anywhere, including from any environment behind NAT (e.g. private clouds, private on-prem, your own laptop, IoT, etc...). For example, you can host or test your website or API running on your own laptop and expose it publicly. Octelium supports both anonymous access (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/anonymous-access.md)) as well as secure zero trust client-based and clientless BeyondCorp access (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/clientless.md)). This guide focuses on anonymous access for HTTP-based resources behind NAT.

Let's assume that the *User* who is supposed to serve the internal resource has the name `john`. Let's create the *User* `john` in `users.yaml` file as follows:

```yaml
kind: User
metadata:
  name: john
spec:
  type: HUMAN
  email: john@example.com
```

Now, we assume that the HTTP-based resource (e.g. web app, API, etc...), to be served at `john`'s side, is listening over the address `localhost:8000`. We simply create the *Service* for our internal resource with the name `svc1` in separate `services.yaml` file as follows:

```yaml
kind: Service
metadata:
  name: svc1
spec:
  mode: WEB
  #!mark(1:2)
  isPublic: true
  isAnonymous: true
  config:
    upstream:
      url: http://localhost:8000
      user: john
```

Now for `john` to actually serve the *Service* `svc1` from his side, `john` needs to connect to the *Cluster*, from his laptop, through the `octelium connect` CLI command and adds the `--serve` flag as follows:

```bash
export OCTELIUM_DOMAIN=<DOMAIN>
octelium connect --serve svc1
```

You can also serve multiple *Services* simultaneously as follows:

```bash
octelium connect --serve svc1 --serve svc2
```

Also you can also serve all *Services* assigned to be served by the *User* via the `--serve-all` flag as follows:

```bash
octelium connect --serve-all
```

Now, the website/API can be publicly and anonymously accessed over the URL `https://svc1.<DOMAIN>`.

Serving your websites or APIs from anywhere behind NAT is not the only way. In Octelium, you can also automatically deploy your containers and serve them as *Services*. Here is a simple example:

```yaml
kind: Service
metadata:
  name: svc1
spec:
  mode: WEB
  isPublic: true
  isAnonymous: true
  config:
    upstream:
      container:
        container: nginx
        port: 80
```

Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for HTTP [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#visibility)). You can read more about visibility [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md).

This was a very short guide to show you how to use Octelium to deploy, scale, route and provide secure access as well as anonymous public access to any webapp containers. Here are a few more related features that you might be interested in:

- Routing not just by request paths, but also by header keys and values, request body content including JSON (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#json-request-body)).
- Request/response header manipulation (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#header-manipulation)).
- Cross-Origin Resource Sharing (CORS) (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#cross-origin-resource-sharing-cors)).
- gRPC mode (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#grpc-mode)).
- Secretless access to upstreams and injecting bearer, basic, or custom authentication header credentials (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#secretless-access)).
- Application layer-aware ABAC access control via policy-as-code using CEL and Open Policy Agent (read more [here](https://octelium.com/docs/octelium/latest/management/core/policy.md)).
- OpenTelemetry-ready, application-layer L7 aware auditing and visibility (read more [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md)).