Octelium can very easily operate as a scalable self-hosted, free and open source alternative to ngrok and similar tunneling-based remote access commercial products to provide secure remote access for yourself and your coworkers (read more about the client-less access mode here) to your HTTP-based resources behind NAT such as Next.js/Vite.js/Astro web web-apps, HTTP/gRPC-based APIs and even to non-HTTP based Services via the client-based access mode (read more here). Octelium can also provide anonymous access (read more here) exposing the resource to the public internet which can be useful for hosting websites and public APIs for example.

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:

1
kind: User
2
metadata:
3
  name: john
4
spec:
5
  type: HUMAN
6
  email: [email protected]

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

1
kind: Service
2
metadata:
3
  name: svc1
4
spec:
5
  mode: HTTP
6
  port: 80
7
  isPublic: true
8
  config:
9
    upstream:
10
      url: http://localhost:8080
11
      user: john

You can now apply the creation of the User and Service as follows (read more here):

export OCTELIUM_DOMAIN=<DOMAIN>
octeliumctl apply /PATH/TO/ROOT_DIRECTORY

You can also expose your Service to anonymous access over the internet (read more about anonymous access here). This allows you to simply publicly serve your internal resources behind NAT from anywhere which can be useful for hosting-related purposes (e.g. publicly hosting your websites, blogs, public APIs, etc...). To use the anonymous mode, you only need to enable the isAnonymous field as follows:

1
kind: Service
2
metadata:
3
  name: svc1
4
spec:
5
  mode: HTTP
6
  port: 80
7
  isPublic: true
8
  isAnonymous: true
9
  config:
10
    upstream:
11
      url: http://localhost:8080
12
      user: john

Now we move on to access control. By default, no Service can be accessed unless explicitly set by a Policy (you can read more in detail about Policies and access control here). For example, we can allow all Users to access our Service as follows:

1
kind: Service
2
metadata:
3
  name: svc1
4
spec:
5
  mode: HTTP
6
  port: 80
7
  isPublic: true
8
  config:
9
    upstream:
10
      url: http://localhost:8080
11
      user: john
12
  authorization:
13
    inlinePolicies:
14
      - spec:
15
          rules:
16
            - effect: ALLOW
17
              condition:
18
                matchAny: true

Octelium actually provides a rich layer-7 aware, identity-based, context-aware ABAC access control on a per-request basis where you can control access based on the HTTP request's path, method, and even serialized JSON body content using policy-as-code with CEL and Open Policy Agent (OPA) (You can read more in detail about Policies and access control here). Here is another more detailed example:

1
kind: Service
2
metadata:
3
  name: svc1
4
spec:
5
  mode: HTTP
6
  port: 80
7
  isPublic: true
8
  config:
9
    upstream:
10
      url: http://localhost:8080
11
      user: john
12
  authorization:
13
    inlinePolicies:
14
      - spec:
15
          rules:
16
            - effect: ALLOW
17
              condition:
18
                all:
19
                  of:
20
                    - match: ctx.user.spec.email.endsWith("@example.com")
21
                    - match: ctx.request.http.path.startsWith("/prefix1")
22
                    - match: ctx.request.http.method in ["GET", "POST"]

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

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

You can also serve multiple Services simultaneously as follows:

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:

octelium connect --serve-all

Now authorized Users, once authenticated for example by Github OAuth2, OpenID Connect or SAML IdentityProviders such as Okta or Azure AD/Microsoft Entra ID (read more here), can access the Service svc1 either via the client-based private mode via the octelium connect command (read more here) as follows:

export OCTELIUM_DOMAIN=<DOMAIN>
octelium connect

curl http://svc1

Authorized Users can also access the Service via the client-less (i.e. BeyondCorp) mode (read more here). For example, if the Service is a web app, HUMAN Users (read more about User management here) can simply access the Service via their browsers at the public URL https://svc1.<DOMAIN>. Authorized WORKLOAD Users can also access the Service in a client-less way via standard OAuth2 client credential flow (read more here) or even directly via bearer access tokens (read more here).

Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for HTTP here). You can read more about visibility here.

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).
• Request/response header manipulation (read more here).
• Cross-Origin Resource Sharing (CORS) (read more here).
• gRPC mode (read more here).
• Secret-less access to upstreams and injecting bearer, basic, or custom authentication header credentials (read more here).
• Application layer-aware ABAC access control via policy-as-code using CEL and Open Policy Agent (read more here).
• OpenTelemetry-ready, application-layer L7 aware auditing and visibility (read more here).