Skip to main content

Platform / Connector

Enterprise connector

The Connector runs beside your app, connects out to LayerV, and carries approved traffic. What it needs to run in production, typically in Docker: CPU, memory, storage, network, and the deployment steps.

Start with 1 vCPU and 256 MiB RAM for the Connector. Runs on Linux AMD64 and ARM64. Add your app’s resources separately. [14]
Deploy the ConnectorSources

Sharing an app from your own machine? Use the qURL™ CLI →

How the Enterprise connector fitsThe Connector runs beside your app container on your Docker host, sharing its network namespace to reach the app on localhost, and opens an outbound connection to LayerV, which grants approved people and approved agents access.Your Docker hostApp containerPublic ports stay closedShared networknamespaceEnterprise connectorlocalhostOutbound connectionLayerVApproved peopleApproved agents

Environment requirements

Confirm your infrastructure can run the Connector.

Host and platform
RequirementDetail
HostLinux Docker host with permission to create containers and persistent storage. [1][2]
OS & CPUDocker with 64-bit Linux containers. The released image includes linux/amd64 (x86-64) and linux/arm64. Docker selects the matching platform from the multi-platform image digest. [8] Measured v2.5.3 image manifest.
GPUNone required. [14]
DiagnosticsThe Connector image contains no shell or package manager. Use host tools for diagnostics. [1]

Storage capacity

Plan the storage the Connector container needs on the host.

Connector storage budget
StorageStarting allocationDetail
Image cache128 MiBPlanning allowance for the measured v2.5.3 image plus a second copy during an update. Check the image size again when selecting a newer release. Measured Docker image storage: arm64 39.4 MiB; amd64 43.8 MiB. This excludes Docker’s own data and your app image. Image details.
Persistent state1 GiB per deploymentSuggested starting allowance, not measured state consumption. Mount persistent state at /var/lib/qurl and pass that path as --state-dir. Monitor disk use. Keep it across restarts and upgrades. [2][3]
Temporary files64 MiB maximumMount /tmp as memory-backed storage with size=64m. This is a ceiling, not a permanent 64 MiB allocation, and it shares the container RAM budget. [2][11]
Container logs3 files × 10 MBUse Docker’s JSON logging driver with max-size=10m and max-file=3 for a bounded local starting policy. This is separate from persistent state; use your log platform for longer retention. [10]

CPU and memory

Choose a starting allocation for the Connector container. These allocations were tested on Linux AMD64 and ARM64 with the same controlled workload. [14]

Light workloads

0.25 vCPU

128 MiB RAM

A compact allocation for small HTTP responses.

Recommended starting point

1 vCPU

256 MiB RAM

Start here for more CPU and memory headroom.

Additional capacity

2 vCPU

512 MiB RAM

A larger budget as your deployment grows.

Sizing notesThese are planning allocations, not production capacity guarantees. The tests exercise the Connector runtime with small responses, loopback networking, and scripted admission; they do not measure the complete deployed service or live enrollment. Load-test your deployment before production. Payload size, concurrent connections, and sustained request rate affect resource use. Temporary files share the RAM budget. Reserve separate capacity for Linux, Docker, your app, and other containers. [7]

Container configuration

Configure the image, security settings, runtime limits, and lifecycle behavior.

Container configuration
ConfigurationDetail
Container imageghcr.io/layervai/qurl, published in GitHub Container Registry. This public image contains the Connector runtime. Configure the container to run the service with daemon run; the image alone does not start or enroll a Connector. No source build is required. Pin an approved release digest in your deployment manifest. [9] [1]
Runtime userUID/GID 65532:65532. Use a read-only root filesystem, --cap-drop=ALL, and --security-opt=no-new-privileges:true. A privileged container is not required. [1][2]
Persistent stateCreate the Docker state directory with owner 65532:65532 and mode 0700. Store it on persistent storage and treat it as secret material. Give each independent deployment its own state directory. [2]
Process & file limitsStart with --pids-limit=512 and --ulimit nofile=4096:4096. These are tested allocations; increase them if your measured workload needs more. [2] [14]
Restart behaviorUse --restart=unless-stopped or your orchestrator’s restart policy. If you use --network container:APP_CONTAINER, recreate the Connector with the new app container’s network namespace when you replace the app container. [2]

Network requirements

Outbound access, without a public app port

The Connector opens a reverse tunnel to LayerV and forwards approved requests to your app. Do not publish the app port just to make the Connector work. An app port you already expose still needs to be closed separately. [2][6]

Network checklist
ConnectionDestinationRequirement
DNSYour configured resolverResolve the API, Hub, and assigned tunnel endpoints. [4][6]
Outbound HTTPS (TCP 443)api.layerv.aiAllow account and sharing-state requests to the configured qURL API endpoint. Use the endpoint for your deployment environment. [15]
Outbound UDP 443hub.nhp.layerv.ai and assigned NHP cellsDirect UDP for admission and registration. An HTTP-only proxy is not sufficient. Use the endpoint and trust settings for your deployment environment. [4]
Outbound TCP tunnelAssigned server host and portAllow direct TCP to the endpoint returned by authenticated admission. Do not assume its port is 443 or hard-code an address copied from another deployment. UDP and TCP must use the same source-IP egress path. [6][12][13]
Local HTTPYour app’s localhost portWith --network container:APP_CONTAINER, the app and Connector share a network namespace. The configured HTTP port must accept connections there. [2]
Image downloadsContainer registryThe Docker host must be able to pull the pinned image. This is host access for installation and updates, separate from the running Connector’s tunnel. [9]

Bandwidth must cover the application traffic carried through the Connector. There is no fixed Mbps requirement independent of payload size and request rate. Include any additional endpoints required by your account setup or optional cloud key provider.

Deploy the Connector

Pull the approved image, prepare its inputs, start the Connector, and verify the route.

  1. Pull the approved image. Use your container registry workflow and deployment pipeline. The published release includes qurl-image.txt with the immutable image reference. Review the release, then pin that reference in Docker, Compose, or your orchestrator. [9]This example pulls release v3.5.0. It downloads the image without starting a service.
    Docker pull
    docker pull ghcr.io/layervai/qurl@sha256:361b597963844bce729aa17ba8fa5490dc2b11723a35e412e626ee532c4e4d5b
  2. Provide the enrollment token. Provide a one-time enrollment-token file for first startup. Mount it read-only and make it readable only by UID 65532 or its dedicated group. Do not put the token in image layers, command arguments, or source control. [5]The share configuration is generated by the platform (the qURL Slack app's admin command today) or by LayerV for your deployment. Contact LayerV before starting the container if you do not have it.
  3. Mount persistent state. Mount a separate persistent state directory for each Connector instance. Use the state directory created with owner 65532:65532 and mode 0700, and keep it on persistent storage across restarts and upgrades. [2]
  4. Start the Connector. Start the container with the account configuration LayerV provides for your deployment. With plain Docker, use bind mounts for the configuration and token files. [5]
  5. Verify access. Confirm outbound access and the local app connection. After enrollment, verify access to the protected app with an authorized qURL link. A running container alone does not confirm that the route serves traffic.

NoteKeep state. Remove the one-time enrollment secret after a verified warm start. First startup uses the supplied enrollment-token file. Follow the documented transition: remove the token argument, verify a warm start with saved state, then remove the secret mount and delete the secret. [5]

Sources

Review the Connector container release assets on the container releases page. Deploy the exact image digest approved for your deployment pipeline. The specification sources record the versions behind each measurement.

Specification sources

CPU and RAM sizing basis (Markdown download) · Container image manifest

  1. Released container definition
  2. Docker runtime, networking, and resource options
  3. Persistent container storage
  4. Hub and UDP port requirements
  5. Container enrollment and warm-start implementation
  6. Assigned tunnel and local app connection
  7. Runtime workload test
  8. Two-platform image checks
  9. Published container image digest (text download)
  10. Docker log rotation
  11. Docker memory-backed temporary storage
  12. Direct tunnel egress
  13. Pinned tunnel TCP default
  14. CPU and RAM sizing basis (Markdown download)
  15. Container account and sharing-state requests

Contact sales

Contact our team for enterprise deployments.

Enterprise starts with a scoped, paid pilot on one application, typically 60 to 90 days, credited in full toward year one if you convert within 60 days. Then an annual package sized to what you protect. Not per seat.