STARM
Documentation

A useful starting point.
A reviewable next step.

Get started with Launchpad and Netkit. Understand the output, validate it in your environment and keep application-specific decisions explicit.

What STARM does today

STARM provides two browser tools: a single-service container configuration generator and an IPv4 address planner. Calculations run locally; there is no cluster connection, account creation or remote deployment.

Open Launchpad for YAML or Netkit for subnet calculations. Copy the output or download it for your own workflow.

Launchpad

  1. Choose Docker Compose or Kubernetes.
  2. Enter your service name, container image and application listening port.
  3. Set CPU and memory limits appropriate for your application.
  4. Review the exposure, health and security options.
  5. Inspect the YAML and compatibility notes, then download it.

Environment variables use one NAME=value entry per line. Blank lines and lines beginning with # are ignored. Duplicate names are rejected. Values are escaped to remain literal through Compose or Kubernetes environment expansion. For secrets, replace the generated plaintext values with your runtime's secret mechanism.

The generator does not pull images, measure resource needs or inspect your application. The default nginx image is a starting example. Pin a version or digest and validate it before production use.

Docker Compose workflow

Download compose.yaml to an empty project directory. The default example binds port 8080 to localhost and runs the application on port 80 inside the container.

docker compose config
docker compose up -d
docker compose ps
curl http://127.0.0.1:8080/

# Stop and remove this example
docker compose down

Port exposure defaults to 127.0.0.1. Choosing all IPv4 interfaces publishes the port on 0.0.0.0; use firewall rules and a suitable HTTPS setup before making an application publicly accessible.

The optional HTTP health check uses wget inside the container. Disable or replace it if your image lacks wget. A Compose health check reports health; it does not automatically restart an unhealthy running container. The restart policy addresses container exits.

Kubernetes workflow

The output contains a Deployment and an internal ClusterIP Service. CPU and memory requests default to half the selected limits. The Deployment has configurable replicas and disables automatic service-account token mounting.

# Requires an existing cluster and configured kubectl
# Create a custom namespace first, if selected
kubectl apply --dry-run=server -f deployment.yaml
kubectl apply -f deployment.yaml
kubectl rollout status deployment/web
kubectl port-forward service/web 8080:80

# In another terminal
curl http://127.0.0.1:8080/

These commands use the default name web and namespace default. Substitute your service name and add -n your-namespace for a custom namespace.

Optional startup, readiness and liveness probes use the selected HTTP path. Readiness controls whether a Pod receives Service traffic; liveness can trigger container restarts; the startup probe allows the application time to initialize. Choose a path and timing that match the application.

Non-root mode uses UID/GID 10001 and drops Linux capabilities. Read-only mode needs writable mounts for any application state or temporary files. Both options are disabled by default because image requirements differ. Add storage, Secrets, ConfigMaps, ingress/TLS and access policies as needed.

Netkit

Enter an IPv4 CIDR such as 10.42.0.17/24. Netkit normalizes it to 10.42.0.0/24 and shows the mask, total addresses and usable range.

  • For /0 through /30, the first and last addresses are excluded from the conventional usable host count.
  • For /31, both addresses are counted for point-to-point links under RFC 3021. Your network equipment must support this use.
  • For /32, the range contains a single host address.

The subnet planner splits the calculator's network into equal, smaller networks. A /24 split into /26 produces four subnets with 64 total addresses each. Large results display the first 64 rows; the total and truncation flag are retained in the JSON export.

The overlap checker compares two complete CIDR intervals and reports identical, contained or disjoint networks. It is address arithmetic, without DNS queries or traffic probes. A non-overlapping plan still needs working routes and security rules.

Current limits

  • Launchpad: one application container per configuration; CPU 0.1–64 cores, memory 16–65,536 MiB, ports 1–65,535 and Kubernetes replicas 1–20.
  • No database stack, persistent volume, ingress, automatic image verification or hosted runtime is included.
  • Netkit: IPv4 only, /0–/32, at most 64 subnet rows in the displayed and exported preview.
  • Tool inputs are not saved between page visits. Download a file if you want to keep your work.

Technical references

The output uses standard Docker Compose and Kubernetes configuration. Consult the upstream documentation when adapting it to your runtime: