How to publish

What "self-hosted" means in practice

There is no editor or upload button on Vivum. The only hard requirement is a stable public URL where the article lives, you host it yourself, wherever makes sense for what you built, and submit that link.

For most articles, that public URL and the source code are the same thing: a plain HTML file, a Distill build, or an exported notebook pushed to a public GitHub repo, served directly by GitHub Pages for free. In that case the repo isn't optional infrastructure, it's the article.

Shiny and Dash articles work differently. They need a live R or Python process, so the thing readers visit is a deployed app on a host like shinyapps.io or Render, not a static GitHub Pages site. You can still keep the source in a public GitHub repo, and you should, it's how reviewers and readers verify the analysis, but the repo isn't what you're linking to as the article itself. The next section walks through which case applies to you.

Choosing a tool for the interactive parts

"Interactive" almost always means a chart or simulation that responds to user input, a slider, a dropdown, a button. The tool you reach for depends on what you already know, not on any Vivum requirement. The table below lists some options, what they're good at, and where they fall short.

If you're unsure, plain HTML with D3 or Plotly.js is the safest default: it's a static file, it hosts anywhere for free, and it's exactly what the Vivum template is built on. For a sense of what this looks like at full scale, read The Living Article , an interactive piece arguing that the web medium changes what a scientific argument can say, built entirely with this approach.

If your analysis already works in R or Python and the gap is purely on the web side, you don't need to learn HTML, CSS, or D3 from scratch to use that default. AI coding tools (e.g. Claude, Gemini, ChatGPT) are well suited to exactly this handoff: provide both the Vivum template and your existing analysis (the script, notebook, or write-up) as context, and it's generally enough for the tool to draft the interactive HTML/JS around your results. You're still responsible for checking that it represents the analysis correctly, but it removes the need to become a frontend developer first.

A minimal worked example

Here is the entire pattern behind the interactive figures in The Living Article , for instance the ROC explorer and the likelihood-surface descent: an SVG element sits in the HTML, a slider sits next to it, and a short script redraws the SVG whenever the slider moves. Nothing here is Vivum-specific, it's the same D3 you'd write for any static site.

<!-- 1. Load D3 from a CDN, no build step, no install -->
<script src="https://cdn.jsdelivr.net/npm/d3@7/dist/d3.min.js"></script>

<!-- 2. Somewhere in your article body -->
<svg id="my-figure" width="600" height="300"></svg>
<input type="range" id="param-a" min="0" max="100" value="50" />

<script>
  // 3. Draw once on load, redraw whenever the slider changes
  function draw(value) {
    const svg = d3.select('#my-figure');
    svg.selectAll('circle').remove();
    svg.append('circle')
      .attr('cx', 300)
      .attr('cy', 150)
      .attr('r', value)
      .attr('fill', '#0A6B3B');
  }

  draw(50);
  document.getElementById('param-a')
    .addEventListener('input', (e) => draw(+e.target.value));
</script>

Save that as index.html, push it to a public GitHub repo, enable GitHub Pages, and you have a live, interactive article with a real public URL, no framework required. The Vivum template starts from exactly this pattern and adds the page layout, table of contents, sidenotes, and citation block around it.

Hosting it publicly

Your article needs a stable public URL, and ideally a public repo behind it. GitHub Pages is the default choice for anything that's a static file (plain HTML, Distill, Observable export, Jupyter Book export): it's free, version-controlled, and serves directly from the repo you just pushed.

Submitting to Vivum

Once your article is live, submit it using the form. After approval, it'll enter the public feed immediately, where the community can read, comment, upvote, and nominate it for review.

Submit the repository URL alongside the live URL whenever your code lives in one, this is the case for plain HTML, Distill, Observable exports, and Jupyter Book articles, where the repo is what lets readers inspect the code, reproduce the analysis, and verify every interactive claim independently. For Shiny or Dash articles, link the repo too if you have one public; if your code only lives in a private deployment, that's acceptable but worth disclosing in the submission notes, since it limits how readers can verify the analysis.

If the article accompanies a peer-reviewed publication, you can optionally add a published paper URL (DOI or journal link) at submission time. This positions Vivum as a complementary interactive layer on top of the formal paper.

Keeping your article up to date

Vivum links to your article rather than hosting a copy, so every update happens on your end: push to GitHub, redeploy to shinyapps.io or Render, whatever applies to your setup. For changes that affect the scientific content (new results, revised methodology, corrected figures), visit your article's page on Vivum and use the Version history section to log what changed.

Typo fixes and styling tweaks don't need to be logged. Reserve version notes for changes a reviewer or reader would actually want to know about.

On approval, we also snapshot your article using the Wayback Machine. That way, we save a permanent record of what the article looked like when it was first indexed. Version history is what tracks everything that happens after that: each confirmed update is logged with a description and a timestamp, so the two together give a full picture, what it looked like at the start, and what changed since.

What happens after submission