Deployment#

GeoTwin runs either as an appliance with the platform pre-installed or as a server installation on your own infrastructure. This page covers the server path; appliance users can start with Quick start.

Deployment models#

System requirements#

The exact baseline depends on data volume, concurrent users and rendering load. The values below are the starting point from the legacy Server manual.

Hardware#

• CPU: 8 cores or more for a pilot; 16 cores or more for production.
• Memory: 32 GB for a pilot; 64 GB or more when many 3D scenes are rendered.
• GPU: a discrete GPU is recommended for cloud rendering; integrated GPUs are acceptable for light 2D workloads.
• Storage: SSD for the platform and database; separate, expandable storage for tiles, point clouds and models.

Software#

• Operating system: Windows Server or CentOS 9 (or a compatible Linux distribution).
• Database: PostgreSQL or Dameng DM8.
• Container runtime: Docker, or Kubernetes for a clustered deployment.
• Browser: current Chrome, Edge or Safari with WebGL enabled.

Network#

• Publish the web entry over HTTPS (443). Redirect HTTP (80) to HTTPS.
• Keep database, object storage and internal service ports on the private network.
• Open only the API and cloud-rendering ports that your deployment actually uses.
• For remote sites, test latency before rollout; large tile and point-cloud requests are sensitive to round-trip time.

Installation outline#

1. Prepare the hosts, DNS record and TLS certificate.
2. Install and tune the database; create a dedicated database and user.
3. Prepare file storage for tiles, models, panoramas and attachments.
4. Install the GeoTwin packages and configure the connection strings.
5. Start the services and check the health endpoint.
6. Sign in as the administrator, apply the licence and create the first tenant and project.
7. Import a small data set and publish one service as an end-to-end check.

Keep the installation values (database, storage paths, ports, licence) in your own configuration record. Do not store them in the public repository.

Reverse proxy#

Terminate TLS at nginx or your existing gateway, and forward to the platform service. A minimal server block:

server {
    listen 443 ssl;
    server_name geotwin.your-domain.com;

    ssl_certificate     /etc/letsencrypt/live/geotwin.your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/geotwin.your-domain.com/privkey.pem;

    client_max_body_size 2g;

    location / {
        proxy_pass http://geotwin-app:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Increase client_max_body_size if users upload large point clouds or model packages.

Backup and upgrade#

• Back up the database, the file storage and the configuration before every upgrade.
• Take a snapshot of the host when the platform and database run on the same machine.
• Upgrade during a maintenance window; stop write traffic first.
• After the upgrade, verify login, one published service and one scene before reopening the site.

Operations checklist#

• HTTPS certificate renewal is automated.
• Database and storage backups run on a schedule and have been restored in a test.
• Disk usage alerts are enabled for tile and model storage.
• Administrator accounts use named users, not a shared account.
• The licence and support contact are recorded.

Next#

• Data and services
• Scenes
• FAQ