Install Certimate with Docker and Access It Remotely

Why self-host Certimate?

Certimate is an open-source ACME tool designed to manage the certificate lifecycle through a visual workflow. Its documented capabilities include requesting single-domain, multi-domain, wildcard, and IP address certificates; selecting RSA or ECC keys; using DNS-01 or HTTP-01 validation; exporting formats such as PEM, PFX, and JKS; deploying certificates to supported destinations; sending notifications; and renewing certificates before expiration.

The project is intended for private deployment. Its application data is stored on the system where it runs rather than in a hosted Certimate service. That makes it useful for administrators who want direct control over certificate records, workflow configuration, provider credentials, and deployment settings. Self-hosting also makes the operator responsible for securing the host, protecting the persistent data directory, controlling remote access, installing updates, and maintaining backups.

Certimate documents multiple deployment approaches. A precompiled binary can be downloaded, extracted, and started with ./certimate serve. Docker provides a containerized deployment with a persistent data mount. The documentation also identifies source-code deployment as an available approach, although the supplied evidence does not establish the exact build commands or toolchain requirements for that path. This guide therefore focuses on the official Docker quick-start workflow and does not guess at unsupported source-build instructions.

Understand the deployment and access architecture

It helps to separate four concerns: the Certimate process, Docker's host-port publication, Certimate's persistent data, and the optional Localtonet tunnel. Treating these as distinct layers makes installation and troubleshooting much clearer.

Certimate application layer

Inside the official container, Certimate serves its web interface on port 8090. The official Docker command maps that container port to host port 8090. The documented browser endpoint is http://127.0.0.1:8090, which is the address we use for initial verification.

Persistent storage layer

The container path /app/pb_data holds persistent application data in the documented deployment. The quick-start command bind-mounts a data directory beneath the current host directory to that container path. This separation matters because containers can be stopped, removed, and recreated, while the mounted host directory remains available.

A container is not a backup. Accidental deletion, disk failure, filesystem corruption, or an unsafe application update can still affect the mounted directory. Include the host-side data directory in an appropriate backup process and test restoration separately from production.

Remote-access layer

Localtonet does not replace Certimate or alter its certificate workflows. Our client runs on the Certimate host, or on another device that can reach the Certimate service, and establishes an outbound connection to a Localtonet relay server. An HTTP tunnel then forwards requests from its assigned public address to the selected local IP address and port.

Creating the tunnel configuration is not the same as running it. The selected Localtonet client must be connected, and the tunnel must be started. The public address remains usable only while that client is connected and the tunnel is running. This lifecycle is useful for an administrative service because an operator can stop the tunnel when remote management is no longer required.

Prerequisites and decisions before installation

Prepare the host before copying the Docker command. Most failed deployments come from missing runtime access, an occupied port, an unsuitable data directory, or an assumption that the public tunnel should be configured before the local service works.

A working Docker installation

The host needs a functioning Docker environment capable of pulling and running Linux container images. Confirm that your user or service account is authorized to communicate with the Docker daemon. Docker installation commands vary by operating system, distribution, package source, and managed-hosting environment, so this article does not provide a generic installation command that could be wrong for your system.

Verify Docker itself before proceeding:

docker version

The command should return client and server information. If it reports that the daemon is unavailable or access is denied, resolve that runtime problem first. Adding broad privileges merely to suppress an error is not a substitute for following the host's Docker security model.

A durable working directory

The official command uses $(pwd)/data as the host side of the persistent mount. That means the directory from which you run the command determines where Certimate's data is stored. Choose a stable location on a suitable filesystem rather than launching the command from a temporary directory, download directory, or path likely to be deleted.

The command syntax shown in this guide follows the project's documented POSIX-style example. The $(pwd) expression is shell syntax that expands to the current directory. If the Docker host uses a shell that does not support that syntax, use the equivalent absolute host path accepted by that environment. Do not alter the container destination /app/pb_data without current project documentation confirming another supported layout.

Port 8090 availability

The documented deployment publishes host port 8090. Check whether another application or container already uses it. The exact inspection command depends on the operating system, but Docker containers can be reviewed with:

docker ps

If port 8090 is occupied, do not stop an unfamiliar production service without identifying it. Docker can map a different host port to container port 8090, but the project's supplied quick-start evidence documents 8090:8090. This guide retains that documented mapping rather than selecting an arbitrary alternative.

A plan for credentials and recovery

Certimate's published quick start includes a default administrator username and password. Anyone who knows those defaults may try them if the interface becomes reachable. Plan to sign in locally and replace the default password before publishing the interface.

Also identify where backups will be stored, who should have host access, and how certificate-provider credentials will be rotated if the host is compromised. The supplied project evidence states that data is stored locally, but it does not establish that every value in the persistent directory is encrypted at rest. Protect the host directory and its backups as sensitive data.

Localtonet prerequisites for optional remote access

The Localtonet stage requires our client application on a device that can reach Certimate. It also requires a device-specific authentication token, selection of an available relay server or region from the current dashboard, and an HTTP tunnel targeting the local Certimate address and port. Tokens must never be copied into an article, screenshot, shell history, public repository, or support message.

Install Certimate with the official Docker image

The following sequence keeps the project installation first. Localtonet is added only after the application is running and secured.

Run the documented container command

docker run -d \
  --name certimate \
  --restart unless-stopped \
  -p 8090:8090 \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/timezone:/etc/timezone:ro \
  -v $(pwd)/data:/app/pb_data \
  certimate/certimate:latest

The two timezone mounts refer to Linux host paths. Before running the command, confirm that /etc/localtime and /etc/timezone exist on the selected host. If the host platform does not provide those paths, consult the current Certimate deployment guidance and the Docker documentation for that operating system rather than creating arbitrary files or guessing at replacements.

Review the purpose of each option:

• -d runs the container in detached mode.
• --name certimate assigns a stable container name for logs and lifecycle commands.
• --restart unless-stopped asks Docker to restart the container after failures or daemon restarts unless an operator deliberately stopped it.
• -p 8090:8090 maps host port 8090 to Certimate's container port 8090.
• The timezone files are mounted read-only, as indicated by :ro.
• $(pwd)/data:/app/pb_data keeps Certimate's application data in a host-side directory.
• certimate/certimate:latest selects the official image and its moving latest tag.

Check the result:

docker ps
docker logs certimate

The container should appear in the running list. Logs should be inspected for startup failures, mount errors, port conflicts, or repeated restarts. Log wording can vary by release, so success should be confirmed by both container state and an actual browser request.

Secure Certimate before exposing it remotely

Certificate automation systems frequently need powerful credentials. A DNS-01 workflow may need permission to create validation records. Deployment workflows may connect to cloud platforms, Kubernetes environments, CDNs, load balancers, WAFs, or remote systems. A compromised administration account can therefore have consequences beyond the Certimate host.

Replace the published administrator credentials

The documented initial account is:

Username: admin@certimate.fun
Password: 1234567890

These are bootstrap credentials, not safe production credentials. Use them only for the initial local sign-in, change the password immediately, and do not reuse a password from another service. The supplied evidence does not establish the exact password menu path or additional authentication features for every release, so verify the controls exposed by the installed version rather than relying on an old screenshot or assumed menu name.

Apply least privilege to provider credentials

When configuring a DNS provider or deployment destination, create credentials limited to the operations and resources the workflow requires. For example, a certificate workflow should not receive organization-wide administrative access merely because broad credentials are easier to create. Provider-specific permission names vary, so follow the provider's current permission model.

Rotate credentials periodically and after any suspected exposure. Remove credentials for providers or deployment destinations that are no longer used. Avoid placing secrets in shell commands, screenshots, exported diagnostics, issue reports, or public repositories.

Protect the persistent directory

The host-side data directory should be readable only by the accounts and services that genuinely require it. Protect backup copies to the same standard. The fact that Certimate is self-hosted means the operator controls the storage location, but local storage by itself does not guarantee confidentiality.

Do not casually edit files inside the persistent directory while Certimate is running. The documented material supplied for this guide does not define a supported manual-editing procedure or database repair workflow. Use the application interface for normal configuration and make a verified backup before maintenance.

Consider the Docker port binding

Docker's -p 8090:8090 syntax commonly publishes the host port on available interfaces according to the Docker daemon's networking behavior. The fact that the project tells users to browse to 127.0.0.1:8090 does not by itself prove that other devices cannot reach the port.

Check the effective port binding with:

docker port certimate

Also test from the relevant network boundary or inspect the host's listening sockets using the tools appropriate for its operating system. If your deployment requires a loopback-only binding, Docker supports an explicit host address in the publication syntax:

-p 127.0.0.1:8090:8090

That is a security-oriented adaptation rather than the exact Certimate quick-start command. If Localtonet runs directly on the same host, it can target 127.0.0.1:8090. If our client runs on another device, a loopback-only Certimate binding will not be reachable from that device. Choose the network arrangement deliberately instead of exposing the port broadly and assuming it is private.

Verify the local Certimate deployment

Verification should prove more than the existence of a container. A useful acceptance test checks the process, the web interface, authentication, persistence, and restart behavior before remote access is added.

Check container status

docker ps --filter name=certimate

Confirm that the expected container is running and that its port publication matches the intended host configuration. If it repeatedly disappears and returns, inspect whether it is restarting because of an application, mount, or configuration failure.

Inspect recent logs

docker logs --tail 100 certimate

Look for errors involving the persistent path, permissions, unavailable files, or port startup. Do not publish complete logs without reviewing them for domains, account names, provider details, credentials, or other sensitive configuration.

Open the documented endpoint

On the Docker host, browse to:

http://127.0.0.1:8090

A successful test should render Certimate's web interface. A browser connection error indicates a local problem that should be resolved before Localtonet is involved. A tunnel cannot make an unhealthy target healthy.

Confirm the administrator account is secured

Sign in locally, change the default password, sign out, and verify that the default password no longer grants access. Then sign in with the replacement credentials. This confirms that the credential change was actually accepted rather than merely entered into an unsaved form.

Test persistence across a restart

After changing a harmless setting or confirming an account change, restart the container:

docker restart certimate

Wait for the application to return, reopen http://127.0.0.1:8090, and confirm that the expected state remains. This checks that the host-side data mount is functioning. It does not replace a restore test, but it can reveal an accidental ephemeral deployment before important workflows are created.

Separate application verification from certificate workflow testing

A working dashboard proves that Certimate is running. It does not prove that a particular ACME account, DNS provider, HTTP-01 route, certificate authority, deployment target, or notification channel is configured correctly. Test those integrations individually with least-privilege credentials and noncritical targets before relying on automatic renewal in production.

Operate, back up, and update the container

Routine operations should preserve the persistent directory and avoid accidental recreation with a different mount. Record the original working directory, image choice, port binding, timezone mounts, and any approved security adaptations.

Start, stop, and restart Certimate

docker stop certimate
docker start certimate
docker restart certimate

Stopping the container makes the local web interface unavailable. If a Localtonet tunnel remains started while Certimate is stopped, the public address will not have a healthy local target. For planned maintenance, stop the tunnel as well so users do not mistake an intentionally unavailable service for an unexplained outage.

Review logs safely

docker logs --tail 200 certimate

Use logs to investigate startup and workflow failures, but handle them as potentially sensitive operational data. When sharing a small excerpt with an authorized administrator, remove secrets and unrelated identifying details without deleting the actual error context.

Back up persistent state

Back up the host directory represented by $(pwd)/data. A dependable backup process should document whether Certimate must be stopped for consistency, where copies are stored, how long they are retained, and how restoration is tested. The supplied project evidence does not define an official backup command or guarantee that copying live files produces an application-consistent snapshot, so do not invent such a guarantee.

For a conservative maintenance window, stop Certimate, create the backup using the organization's approved filesystem or storage tooling, and start the container again. Validate the service locally after startup. More advanced snapshot methods may be appropriate when the underlying storage platform provides consistency controls, but those methods are platform-specific.

Understand the moving image tag

The official quick-start command uses certimate/certimate:latest. A moving tag can refer to a newer image when it is pulled later. Restarting an existing container does not by itself replace it with a newly pulled image. Updating generally involves reviewing release information, backing up persistent data, pulling the intended image, and recreating the container with the same approved settings.

A basic pull command is:

docker pull certimate/certimate:latest

Pulling does not update the already-created container. Before recreating it, preserve the exact deployment parameters and verify that the current Certimate release does not require migration steps. The supplied evidence includes migration-related documentation but does not establish one universal upgrade sequence for every version transition. Review version-specific requirements before deleting the existing container.

If the release is compatible and the data backup is complete, the normal Docker lifecycle is to stop and remove the old container, then run a replacement using the same persistent host directory:

docker stop certimate
docker rm certimate

After removal, rerun the approved docker run configuration from the same working directory. Do not run it from an unrelated directory, because $(pwd)/data would then point at different storage and the new container could appear to have lost its configuration.

Access Certimate remotely through a Localtonet HTTP tunnel

Add remote access only after the local acceptance checks pass. With Localtonet, the client establishes an outbound connection to our relay infrastructure, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The HTTP tunnel points to the existing Certimate IP address and port and provides a public HTTPS address.

HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain as their Process Type. All three serve the target content at a public HTTPS address. Availability and exact choices can vary, so use the options currently shown in the dashboard. Custom-domain DNS requirements must be checked against current documentation before changing DNS records.

The target address depends on where our client runs. If Localtonet runs directly on the Docker host, 127.0.0.1:8090 can reach the host-published port. If the client runs on another LAN device, 127.0.0.1 refers to that other device and will not reach the Certimate host. In that arrangement, use an address that is reachable from the client and ensure the Docker port binding permits that path.

You can review the current platform workflow in the Localtonet documentation. Always use the current dashboard values for tokens, relay selection, tunnel options, and generated public addresses.

Recommended remote verification sequence

1. Confirm that http://127.0.0.1:8090 still works on the Certimate host.
2. Confirm that the documented default password no longer works.
3. Confirm that the Localtonet client is connected.
4. Confirm that the HTTP tunnel is started.
5. Open the assigned HTTPS address from a device outside the local network.
6. Sign in using the replacement administrator credentials.
7. Perform only the intended administrative work.
8. Sign out and stop the tunnel if continuous access is unnecessary.

Avoid treating a difficult-to-guess URL as an authorization mechanism. Anyone who obtains the address can reach the exposed sign-in page while the tunnel is active. The application password, credential hygiene, least-privilege provider access, and controlled tunnel lifecycle remain essential.

Troubleshoot installation and remote access

The container name is already in use

Docker will not create another container named certimate while an existing container has that name, even if it is stopped. Inspect all matching containers:

docker ps -a --filter name=certimate

If it is the intended installation, start or inspect it rather than creating a duplicate. Remove it only after confirming that its persistent storage is correctly mounted and protected.

Port 8090 is already allocated

Another process or container is using the requested host port. Inspect running containers and the host's listeners. Identify the existing service before changing anything. If a different host port is required, remember that the container still listens on 8090 and that Localtonet must target the actual host-side port. This guide does not select an arbitrary replacement because port policy is environment-specific.

The container exits or continuously restarts

docker logs --tail 200 certimate
docker inspect certimate

Look for missing timezone paths, inaccessible mounts, invalid filesystem permissions, image startup errors, or other host-level failures. The restart policy may make a broken container appear intermittently in the running list, so inspect both its current state and logs.

The browser cannot reach 127.0.0.1:8090

Confirm that the browser is running on the Docker host. The address 127.0.0.1 always refers to the device making the request. If the browser runs on another computer, it points back to that computer, not the Certimate server.

Next, verify that the container is running and that Docker published the expected port:

docker ps --filter name=certimate
docker port certimate

Resolve local reachability before investigating Localtonet. If the service does not answer locally, changing tunnel settings will not correct it.

Certimate appears empty after container recreation

The replacement container may have been launched from a different current directory. Because the documented bind mount uses $(pwd)/data, changing directories changes the host storage path. Stop before creating new configuration, inspect the mount, and locate the original data directory.

Docker's inspection output can help identify mounted host and container paths:

docker inspect certimate

Do not merge directories or overwrite files blindly. Restore from a verified backup or recreate the container with the correct original host directory.

The public Localtonet address does not load

Check the layers in order:

1. Verify Certimate locally at the target address and port.
2. Verify that the Localtonet client is running on the selected device.
3. Verify that the selected device is connected.
4. Verify that the HTTP tunnel targets the correct IP address and port.
5. Verify that the tunnel has been started, not merely created.
6. Retest the assigned public address.

If the client is on another device, test whether that device can reach the Certimate host directly. A loopback-only Docker binding intentionally prevents another machine from reaching the service.

The public address loads the wrong application

Confirm the local target port and inspect which service is actually listening there. A wrong page usually indicates an incorrect target address, an unexpected port mapping, or another service occupying the selected host port. Do not solve this by exposing additional ports until the process ownership is understood.

Certificate issuance fails even though remote administration works

The administration tunnel and ACME challenge are different paths. A working dashboard only proves that an administrator can reach Certimate. For DNS-01, inspect DNS provider authorization, zone selection, and record propagation. For HTTP-01, verify that the challenge route satisfies the certificate authority's public validation requirements. Also inspect the selected certificate authority, requested names, workflow logs, and provider permissions.

The service works, but timezone behavior is unexpected

Confirm that the host timezone files exist and that the container received the documented read-only mounts. Timezone handling varies across host operating systems. Do not create fake timezone files solely to make the command execute. Use platform-appropriate guidance when the documented Linux paths are unavailable.

Frequently asked questions