One more way to run Virtuoso: subscribe, and leave the running of it to us.

One server. One subscription. No build.

You choose a term and a tier. OpenLink runs the machine. That is the whole arrangement — and it is enough.

The guide is about one thing, and it says so in its first line: buying, setting up, and running one Virtuoso SaaS Single Server instance. Behind your subscription sits Virtuoso itself — the multi-model server from OpenLink Software, which holds tables and RDF data in one engine. But on this path you never build it. You never install it. You never patch it. The portal creates one tenant instance for your subscription, and your work moves up a level, where it belongs: the contract, the access, the daily running, the bill.

Read the live offer. Not the screenshot.

The guide’s first rule of evidence: the prices in the pictures are illustrations. Only the live offer counts.

Four checks come before any money moves. Sign in to the right AWS account. Read the live offer whole — term, plan, taxes, metered overages, EULA, support, renewal. Give an email address that will still be yours when the portal account needs looking after. And keep the Marketplace tab open until the confirmation offers you ‘Set up your account’. Then six moves: view the purchase options; pick a duration — 12, 24, or 36 months; pick exactly one plan dimension; look at the usage-based charges that ride on top of the contract price; accept the terms; choose your renewal setting; subscribe. A Marketplace agreement is a commercial contract. The guide respects you enough to say so plainly: switching off auto-renewal stops the next renewal. It does not end the term you are in.

Three doors into the same server

Conductor for looking after it. SPARQL for asking it questions. SQL over TLS for everything else — behind a door that stays shut until you say who may knock.

The instance detail page is where the truth lives: service tier, region, endpoints, and a masked database password, every item belonging to the tenant named there. The first query is the smallest one the language allows — SELECT * WHERE { ?s ?p ?o } LIMIT 10 — a deliberate modesty: if that answers, you are in. The SQL door is the guide’s best piece of design. TLS SQL access is closed by default. It opens only for the trusted public IPv4 CIDRs you type in yourself. And 0.0.0.0/0 is not permitted. Treat the dba password as you would your house keys — shown to you on that page, and meant for no other place. When you want proof you have arrived, one command gives it: status(); answers with the server’s name, its version 08.03.3335-pthreads for Linux, and its registration — Virtuoso-AWS-ECS-FARGATE-SaaS.

The starter query and the status line, verbatim

The guide makes claims you can check. Its first query asks for ten triples of anything at all. Its proof of connection is a single status line. Here are both, exactly as written, and both are kept in the companion Turtle as typed entities.

SELECT * WHERE { ?s ?p ?o } LIMIT 10

isql <tenant-hostname>:1112 -E dba

SQL> status();
OpenLink Virtuoso VDB Server
Version 08.03.3335-pthreads for Linux
Registered to Virtuoso-AWS-ECS-FARGATE-SaaS

SELECT * WHERE { ?s ?p ?o } LIMIT 10

Stop is not delete. Delete is not cancel.

Running the service, day to day, is mostly a matter of keeping three verbs apart.

Stop Instance halts your tenant and keeps its data safe. Start Instance brings it back, health checks and all. Delete Instance ends the tenant’s infrastructure — and it is not, the guide insists, a way to cancel or change your Marketplace agreement. That lives in a different system, under different terms. Around those three verbs sits the heavier work: a shell inside the container through ECS Exec, with IAM material made for you alone and a runbook to follow; online backup, with restore kept under control because the server must be stopped before its database files are replaced; and a Usage & Billing page whose figures are estimates, honestly labelled, under an invoice that only AWS Marketplace may send you.

Backups are yours to run. Restores are not.

The main guide only pointed at this door — a backup location, a generated script, a runbook behind a link. The companion Backup and Restore Guide opens it. What it says can be put in one sentence: you may protect your database whenever you like, but the one operation that can throw the present away is kept in OpenLink’s hands, with your written permission.

Before you start, four things must be in place: access to the buyer portal; a running instance; buyer AWS IAM credentials carrying the one-time shell-access policy described in the Buyer Container Shell Access Runbook; and AWS CLI v2 with the Session Manager plugin on the workstation that will run the script. And one discipline runs through everything that follows: the portal’s script is made for your tenant alone. Never reuse a script from another buyer, another instance, or another environment.

The backup itself is almost disappointingly simple, which is the point. Six moves in the portal and a terminal; then the generated script does five things on its own, ending with the only success signal that counts: the Fargate sync task’s exit code, 0. And when that first run succeeds, something larger begins — a full backup chain, to which the service’s daily workflow keeps adding incremental backups, copied to the same durable S3 location.

Run an online backup

What the generated script does

What your restore request must include

What OpenLink does next

Validate after the restore

When the script finishes, write four things down. Not eventually — then, while the terminal is still open:

• The instance ID and the project name.
• The completion date and the UTC time.
• The backup prefix, or the backup-set timestamp.
• The script output confirming the S3 sync completed successfully.

The S3 bucket is managed by OpenLink. Record the prefix; do not alter, delete, or replace anything under it. If you ever need independent proof of what is stored there, ask OpenLink support — with the instance ID and the reported backup prefix, which is why you wrote them down.

And if the day comes when you need to go back? You do not go back yourself. You ask, in a support request that carries six items — they are steps 12 to 17 above — and OpenLink does the five things that follow them: verifies, takes a rollback copy of the database you are about to leave, stops the tenant, restores, restarts, and confirms the service is healthy before confirming the result to you. Notice the rollback copy. Even the way back has a way back.

After the restore, you validate — steps 23 to 27 — in the portal, in Conductor, and in your own workload, and if the restored state matters, you protect it at once with a new online backup. Things go wrong here in four known ways, each with a short remedy:

Four cases, four remedies

Things go wrong in exactly four ways, says the guide: no instance, the wrong user, a dead setup link, a silent SQL port. Each remedy is short, because each cause is single — a break somewhere in the chain that binds one AWS account, one portal account, and one tenant.

Cited works

• Virtuoso SaaS Managed Service Buyer Guide — OpenLink Community
• Virtuoso SaaS Managed Service Buyer Backup and Restore Guide — OpenLink Community
• Virtuoso SaaS Single Server — AWS Marketplace product page — AWS Marketplace (checked 2026-10-20)

Successful onboarding, defined

A sale is not finished when the order is signed. The guide knows it. You are onboard when seven things hold at once — subscription, account, instance, endpoints, access, credentials, renewal — and every one of them has been checked, not assumed.

• Marketplace subscription completed for the intended buyer AWS account.
• Buyer portal account created or signed in.
• Instance status is running and health is healthy.
• Conductor and SPARQL endpoint links respond.
• TLS SQL works from an explicitly allowed CIDR and is rejected outside it.
• Database credentials have been stored securely.
• Renewal preference has been reviewed in AWS Marketplace.