The Punkolink Cloud

The cloud, layer by layer

Five layers on one platform, from the network edge down to the database core. Take one, or stack them into the shape your application needs. Provisioned in minutes, priced by the minute.

Layer 01 — Network

Network

Network is the outward-facing layer. The address your users reach, the forwarding and filtering in front of your services, and our application-level router — four services, from a raw IP address up to per-route application control.

The Network layer

Rent IPv4

A dedicated IPv4 address, rented as the fixed entry point to your stack. Traffic arrives here before any forwarding or routing rules apply.

Rent IPv6

A dedicated IPv6 address, for reaching your services over IPv6 or offering an IPv6 endpoint alongside IPv4.

L3 — Forwarding and Firewall

Forwarding by IP and port, with packet filtering at the network layer. Allow and deny rules decide what reaches your services before any application-level logic runs.

L7 — Application-level network control

Punkolink L7, our layer-7 router: routing, load balancing, access control, rate limiting, and protection, per route. Run it as a managed service here, or take the single binary and run it on your own infrastructure. Its full feature set is below.

Inside L7 — Routing & Reliability

Load balancing

Traffic is distributed across multiple backend servers rather than concentrated on one. This keeps any single node from becoming a bottleneck under load, and lets capacity be added by attaching more backends behind the same route.

Redundancy

When a backend fails, traffic is redirected to the ones still healthy, so the loss of a single server does not take the service down. Failover is handled at the router, without the client noticing which node answered.

Availability monitoring

The router continuously checks the health of the resources it forwards to, so a failing backend is detected as it degrades rather than when a user reports it. Unhealthy nodes are taken out of rotation until they recover.

Status reporting

The state of routed resources is compiled into reports, giving a record of what was healthy, what failed, and when — the raw material for understanding an incident after it happens and for spotting patterns before one does.

Inside L7 — Access & Protection

Layer-7 access control

Access is defined per route, at the application layer, using role-based rules. Rather than an all-or-nothing gate, each route can require the specific role appropriate to it, so the right traffic reaches the right service with the right permission.

Layer-3 access control

Traffic is filtered by IP address through allow and deny lists, at the network layer. This is the coarse first line — admitting known-good sources or excluding known-bad ones before finer rules apply.

Rate limiting

The rate of requests is capped so that a burst — whether an abusive client or an unexpected spike — cannot overwhelm a backend. Limits are applied at the router, protecting services that have no rate control of their own.

Brute-force protection

Repeated credential-guessing attempts against a login or endpoint are detected and blocked, so an automated attack cannot grind against authentication indefinitely.

Bot protection

Automated bot traffic is identified and filtered away from services, separating real users from scripts, scrapers, and probing tools before they reach the backend.

Graphical challenge

A CAPTCHA-style visual challenge can be interposed to separate human users from automated traffic, used where a request pattern is suspicious enough to warrant proof that a person is behind it.

Inside L7 — Operations

Static file storage

Static assets — for example a site's static markup — can be served directly from the router, without routing those requests to a separate backend at all.

Web GUI

The router is administered through a browser-based panel, so routes, access rules, and backends can be managed without working solely from the command line.

Layer 02 — Executable

Executable

Bring your own code. Upload an aarch64 binary or a Node.js project. The artifact is stored as-is and sits inert — nothing is executed, and nothing is billed, until you start it. An Executable is a place your workload waits; DRP is where it runs.

Binary (aarch64)

A compiled binary built for the aarch64 (ARM64) architecture. Other architectures are not accepted — build for aarch64 or use the Node.js option.

Node.js

A Node.js project, uploaded as its source. The runtime is provided when it starts, so there is nothing to compile ahead of time.

Binary (aarch64) Node.js Stored, inert, until you start it Billed only while running
  1. Upload aarch64 binary / Node.js project
  2. Executable Stored, inert — nothing billed
  3. Run
  4. DRP Container + environment
  5. Running instance Live, billed per minute
An Executable waits in storage until you start it. On start, DRP builds the container and brings it up.
Layer 03 — DRP

DRP

Where your Executables run. Hit Run and DRP wraps the artifact in a container with the right environment and brings it up, next to your databases and the rest of your stack — with scheduling, restarts, and per-minute accounting. Behind that, DRP also places workloads across the machines the cloud runs on, so our own services, managed open-source, and your code share them without getting in each other's way.

Run

Start an Executable. DRP builds a container with the right runtime and dependencies for the artifact, brings it up, and keeps it running — restarting it if it exits. Billing starts when it does and stops when you stop it.

Isolated Linux

Need a machine, not just a service? DRP can bring up an isolated Linux environment — a small instance that's yours to work in, with its own filesystem and shell.

Run — start an Executable Isolated Linux Per-minute runtime
Layer 04 — In-memory

In-memory

In-memory is managed Valkey. Valkey is an open-source in-memory data store — it keeps its data in RAM, so reads and writes return in well under a millisecond. Use it for the work where speed matters and a relational database is the wrong tool: a cache in front of Postgres, session state, job queues, rate-limit counters, and other short-lived data. Provisioned and kept running, so you get the store without operating it.

Cache in front of your database Session state Job queues Rate-limit counters
Layer 05 — Database

Database

Database is one managed PostgreSQL instance, with three capabilities enabled on top of it. Graph, search, and vectors are extensions on that single instance — one database, one connection string, one thing to back up. Several capabilities, not four separate services to run and keep in sync. PostgreSQL itself is the foundation the other three rest on.

Apache AGE — graph

Graph queries (openCypher) inside the same database, for data with strong connectivity — relationships, paths, networks — that you would otherwise move into a dedicated graph database.

ParadeDB — search & analytics

Full-text search and analytical queries directly in Postgres, over your existing tables, without standing up a separate search cluster or analytics store to keep in sync.

pgvector — vectors

Vector storage and similarity search for embeddings and AI features, kept next to the rows they belong to rather than in a separate vector service.

PostgreSQL — relational core

The managed instance itself: application data, transactions, and the default home for anything structured. The base that Apache AGE, ParadeDB, and pgvector all run on.

Graph (AGE) Search & analytics (ParadeDB) Vectors (pgvector) Relational core (PostgreSQL)

PostgreSQL, Apache AGE, ParadeDB, pgvector, and Valkey are trademarks or marks of their respective owners. Punkolink provides managed hosting of these open-source projects and is not affiliated with or endorsed by them.

Start With One Layer

Create an account, claim 20 free credits, and provision your first layer in minutes.