OpenLink Software · Infrastructure as Code

virtuoso-opentofu: Self-managed OpenTofu Deployments for Virtuoso Universal Server

One consistent OpenTofu workflow to deploy single self-managed Virtuoso instances across AWS, Azure, and Google Cloud — provider baselines, deployment workflow, comparison dimensions, FAQ, glossary, KG Explorer, and SPARQL workbench.

Executive SummaryBy OpenLink Software · OpenLink Software

Synopsis

virtuoso-opentofu is OpenLink Software's public repository of self-managed OpenTofu deployment scripts for OpenLink Virtuoso Universal Server across AWS, Azure, and Google Cloud. It provides a consistent OpenTofu-based deployment workflow: one provider directory per cloud (aws/, azure/, azure/aci/ experimental, gcp/), each self-contained with its own Terraform configuration, helper script, and provider-specific modules, deploying single self-managed Virtuoso instances backed by Virtuoso Open Source 7 or Virtuoso Commercial 8 images. The repository is strictly self-managed: managed SaaS implementation (Marketplace metering, customer and seller portals, control-plane code) is excluded by design, and production use requires an encrypted remote backend because every deployment generates a DBA password that lives in OpenTofu state.

View this analysis as a KG entity
Section 1

Purpose and Scope

The repository provides self-managed OpenTofu deployment scripts for OpenLink Virtuoso Universal Server across supported cloud providers. It is for self-managed deployments only and does not contain the managed SaaS control plane, Marketplace integration, customer portal, seller admin portal, or operational evidence used by the managed service.

Section 2

Supported Providers

Supported providers are AWS (available, ECS Fargate + EFS), Azure (available, Virtual Machine + Managed Disk), Azure ACI (experimental, Container Instances + Azure Files), and Google Cloud (available, Compute Engine + Docker + Persistent Disk + Secret Manager).

Section 3

Usage and Deployment Workflow

Operators choose the cloud provider directory and run OpenTofu from inside that directory (tofu init, validate, plan, apply). Each provider directory is intentionally self-contained with its own README.md, versions.tf, variables.tf, outputs.tf, terraform.tfvars.example, deployment helper script, and provider-specific modules. Multiple deployments are supported within the same cloud account, subscription, or project using separate OpenTofu state per deployment plus a distinct naming prefix such as project_name.

Section 4

Future Variants

Potential future additions under consideration are azure/aks/ (Kubernetes-based Azure variant using AKS with Azure Disk for the live database volume) and gcp/gke/ (Kubernetes-based Google Cloud variant using GKE with Persistent Disk for the live database volume). The current recommended single-instance self-managed baselines remain Azure VM + Managed Disk and GCP Compute Engine + Persistent Disk.

gcp/gke/ variant

Kubernetes-based Google Cloud self-managed variant using GKE with Persistent Disk for the live database volume; under consideration, not yet available.

azure/aks/ variant

Kubernetes-based Azure self-managed variant using AKS with Azure Disk for the live database volume; under consideration, not yet available.

Section 5

Publishing Boundary

Managed SaaS implementation files must not be added to this repository; they remain in the private or full development repository. Excluded by design are AWS Marketplace SaaS registration and metering code, customer and seller portal source code, managed SaaS control-plane Lambda/API/CodeBuild/OpenTofu code, Marketplace private offer JSON files, Marketplace validation evidence, and Terraform or OpenTofu state files and local terraform.tfvars.

Section 6

Provider Baseline Comparison

Head-to-head comparison of the AWS, Azure, and Google Cloud self-managed deployment baselines across compute platform, storage, secrets management, status, recommended baseline, and future Kubernetes path.

virtuoso-opentofu Comparison Ontology

Document-local object properties that link provider comparison dimensions to each provider baseline's approach, for the head-to-head AWS / Azure / GCP comparison.

How-To

How-To Guide

1

Choose a cloud provider directory

Choose the cloud provider directory matching your target cloud: aws/, azure/, or gcp/ (azure/aci/ for the experimental Azure Container Instances variant).

2

Configure terraform.tfvars

Inside the provider directory, copy terraform.tfvars.example to terraform.tfvars and edit it as needed.

3

Initialize OpenTofu

Run tofu init inside the provider directory to download the required providers and modules.

4

Validate the configuration

Run tofu validate to check the OpenTofu configuration for internal consistency and syntax errors.

5

Review the execution plan

Run tofu plan to review the resources that OpenTofu will create, change, or destroy before applying anything.

6

Apply the deployment

Run tofu apply to provision the self-managed Virtuoso instance on the target cloud provider.

7

Secure remote state before production use

All deployments generate a DBA password that is present in OpenTofu state; configure an encrypted remote backend before production use, and pin production container images to a tested release tag or immutable digest rather than latest.

8

Run multiple deployments

Multiple deployments are supported within the same cloud account, subscription, or project: use separate OpenTofu state per deployment plus a distinct naming prefix such as project_name.

FAQ

Frequently Asked Questions

virtuoso-opentofu is OpenLink Software's public repository of self-managed OpenTofu deployment scripts for OpenLink Virtuoso Universal Server across AWS, Azure, and Google Cloud. It deploys single self-managed Virtuoso instances with a consistent OpenTofu-based workflow.

AWS (available), Azure (available), Azure ACI (experimental), and Google Cloud (available). Each provider has its own directory: aws/, azure/, azure/aci/, and gcp/.

The AWS baseline uses ECS Fargate with Amazon EFS, an ECS Fargate + EFS based self-managed deployment.

The Azure baseline uses an Azure Virtual Machine with a Managed Disk; it is the recommended Azure self-managed baseline.

The Azure ACI variant uses Azure Container Instances with Azure Files. It is functional for light tests, but local SQL benchmarking on August 18, 2026 showed unacceptable active-database latency even with Premium Azure Files, so it is marked experimental.

The Google Cloud baseline uses Compute Engine with Docker, Persistent Disk for the live database volume, and Secret Manager for secrets.

Both Virtuoso Open Source 7 and Virtuoso Commercial 8 images are supported where documented by the provider-specific deployment.

Choose the cloud provider directory, copy terraform.tfvars.example to terraform.tfvars and edit it, then run tofu init, tofu validate, tofu plan, and tofu apply from inside that directory.

Yes. Multiple deployments are supported within the same cloud account, subscription, or project; the requirement is separate OpenTofu state per deployment plus a distinct naming prefix such as project_name.

All deployments generate a DBA password that is present in OpenTofu state, so configure an encrypted remote backend before production use.

Pinning to a tested release tag or immutable digest instead of latest ensures production reproducibility and avoids unexpected image drift; the README recommends it for production use.

azure/aks/ (AKS with Azure Disk for the live database volume) and gcp/gke/ (GKE with Persistent Disk for the live database volume). These are future options only.

Managed SaaS implementation files must not be added: no AWS Marketplace SaaS registration and metering code, customer or seller portal source, managed SaaS control-plane Lambda/API/CodeBuild/OpenTofu code, Marketplace private offer JSON files, validation evidence, or Terraform or OpenTofu state files and local terraform.tfvars.

Operators who want to deploy and manage self-hosted Virtuoso infrastructure and do not need any of the AWS Marketplace managed-service implementation.

Glossary

Glossary of Terms

OpenTofu

The open-source, community-driven fork of Terraform; the Infrastructure as Code tool this repository uses to deploy self-managed Virtuoso instances.

Terraform

HashiCorp's Infrastructure as Code tool; OpenTofu is its open-source fork.

Docker

Container platform used by the Google Cloud deployment to run the Virtuoso container image.

Kubernetes

Container orchestration platform underlying the future azure/aks/ and gcp/gke/ variants under consideration.

Infrastructure as Code

Managing and provisioning infrastructure through machine-readable definition files rather than manual processes; the paradigm OpenTofu implements.

Amazon EFS

Amazon Elastic File System, the managed network file storage used for the Virtuoso database files in the AWS baseline.

Azure Virtual Machine

Microsoft Azure IaaS compute service hosting the Virtuoso deployment in the recommended Azure baseline.

Azure Managed Disk

Block-level storage volume managed by Azure, attached to the Virtual Machine as the live database volume.

Azure Container Instances

Microsoft Azure serverless container service used by the experimental ACI baseline.

Azure Files

Microsoft Azure managed file share service used for storage in the experimental ACI baseline.

Compute Engine

Google Cloud IaaS compute service hosting the Virtuoso deployment in the GCP baseline.

Persistent Disk

Google Cloud durable block storage used as the live database volume in the GCP baseline.

Secret Manager

Google Cloud service for storing and managing secrets such as the DBA password in the GCP baseline.

ECS Fargate

AWS serverless compute engine used to run the Virtuoso container in the AWS deployment baseline.

Remote state

OpenTofu state stored outside the local machine; the README requires an encrypted remote backend before production use because a generated DBA password is present in state.

Publishing boundary

The explicit scope rule of this repository: self-managed deployment scripts only; managed SaaS implementation files remain in the private or full development repository.

Knowledge Graph Explorer 151 nodes · 369 links

Interactive graph visualization derived from the companion RDF. Click nodes to resolve, drag to explore. Graph data embedded from companion RDF at generation time.

virtuoso-opentofu: Self-managed OpenTofu Deployments for Virtuoso Universal Server

Nodes: 0 Links: 0
Click SVG to activate zoom, click outside to release | Drag nodes to pin, double-click to unpin
Classes Properties Instances

SPARQL Workbench 11 sample queries

Query this knowledge graph on URIBurner. The editor opens on the canonical SAMPLE entity-type summary (DAV named graph). Pick a recipe, edit freely, then run live or copy.

Sample Queries

Reproduced verbatim from the companion RDF. Execute loads the query into the workbench below and runs it live.

Entity type summary for the virtuoso-opentofu graph
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?type (SAMPLE(?s) AS ?sampleEntity) (SAMPLE(?label) AS ?sampleLabel) (COUNT(?s) AS ?entityCount)
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/virtuoso-opentofu-deepseek_v4flash-1.ttl> {
    ?s rdf:type ?type .
    OPTIONAL { ?s rdfs:label ?label }
  }
}
GROUP BY ?type
ORDER BY DESC(?entityCount)
Provider deployment baselines
PREFIX schema: <http://schema.org/>

SELECT ?deployment ?name ?serviceType ?providerName
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/virtuoso-opentofu-deepseek_v4flash-1.ttl> {
    ?deployment a schema:Service ;
        schema:name ?name ;
        schema:serviceType ?serviceType ;
        schema:provider ?provider .
    ?provider schema:name ?providerName .
  }
}
ORDER BY ?name
Deployment workflow steps
PREFIX schema: <http://schema.org/>

SELECT ?position ?name
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/virtuoso-opentofu-deepseek_v4flash-1.ttl> {
    ?step a schema:HowToStep ;
        schema:position ?position ;
        schema:name ?name .
  }
}
ORDER BY ?position
Provider comparison dimensions
PREFIX schema: <http://schema.org/>
PREFIX cdx: <https://linkeddata.uriburner.com/DAV/demos/daas/ontology-terms#>
PREFIX post: <https://github.com/OpenLinkSoftware/virtuoso-opentofu#>

SELECT ?dim ?dimName ?provider ?approachText
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/virtuoso-opentofu-deepseek_v4flash-1.ttl> {
    ?dim a cdx:ComparisonDimension ; schema:name ?dimName ; post:hasAwsApproach ?awsApproach .
    ?awsApproach schema:text ?awsText .
    BIND("AWS" AS ?provider) BIND(?awsText AS ?approachText)
  }
}
ORDER BY ?dimName

Query editor

▶ Run live on URIBurner SELECT: text/x-html+tr | DESCRIBE/CONSTRUCT: text/x-html-nice-turtle