Sphinx Confluence Relay
Overview
The project provides the ability to create a "relay" service that accepts generated manifest files from Atlassian Confluence Builder for Sphinx (GitHub), powered by Sphinx (GitHub), and publish them to a pre-configured Confluence Data Center instance (Confluence Cloud is not supported). Using such a service allows system administrators to setup publish relaying where users do not need to expose their Confluence tokens.
Requirements
- Python 3.11+
- APScheduler
- FastAPI
- SQLModel
Usage
Users of a running service will publish using at least three key components:
- A data-embedded manifest generated from Atlassian Confluence Builder for Sphinx.
- The key of a space to publish into.
- The parent page name/identifier to publish documentation under.
A publish event will take a manifest and upload all pages/attachments into a given target space. After pages/attachments are uploaded, any legacy content hosted on Confluence will be removed. Publication and removals are contained to the descendants of the configured parent page. Requests that would require moving pages in a space into the parent page's descendants will be ignored.
Publish events are queued. The service can accept multiple requests and will process them in a first-in-first-out (FIFO) order. Pages/attachments are only uploaded if required (i.e. changed).
Users may use the REST interface of a hosted service utilizing any common tools (e.g. curl). Alternatively, if this package is installed on a client system, users may utilize the publish helper tool:
sphinx-confluence-relay-publish --help
(or)
python -m sphinx_confluence_relay --help
For example:
sphinx-confluence-relay-publish http://upload.wiki.example.com/ --space-key MYSPACE --parent-page Documentation
Command line options can be replaced using respective environment options:
SPHINX_CONFLUENCE_RELAY_PUBLISH_PARENT
SPHINX_CONFLUENCE_RELAY_PUBLISH_SPACE
SPHINX_CONFLUENCE_RELAY_PUBLISH_URL
If a manifest file is not provided via the --manifest argument, the default
paths searched for will be:
scb-manifest.json
(or)
_build/confluence/scb-manifest.json
(or)
_build/singleconfluence/scb-manifest.json
If a system administrator has configured authentication requirements, a token can be passed a couple of ways. The utility accepts a token value from the environment:
SPHINX_CONFLUENCE_RELAY_PUBLISH_TOKEN
Passed in using the standard input stream with --password-stdin:
cat ~/.token | sphinx-confluence-relay-publish ... --password-stdin
Or passed in using the --token argument:
sphinx-confluence-relay-publish ... --token <TOKEN>
Service Installation
Configuration
The relay service relies on a TOML configuration file. A template of this configuration can be found in the root of this repository:
sphinx-confluence-relay.toml.default
A system administrator will typically prepare a sphinx-confluence-relay.toml
file on a host. sphinx-confluence-relay will search for configurations found
in the following paths:
sphinx-confluence-relay.toml
(or)
/etc/sphinx-confluence-relay.toml (non-Windows)
The bare minimum configuration required is the configuration of the Confluence Data Center API URL and the token that will be used for REST interaction:
[sphinx-confluence-relay]
confluence-url = 'https://wiki.example.com/rest/api/'
confluence-token = ''
If a system administrator wishes to require tokens for publish requests,
they can register one or more tokens in a publish-tokens option:
publish-tokens = [
'SOME_TOKEN',
]
By default, all spaces the Confluence token can access could be published to.
If an environment is looking to restrict only publishing to specific pages,
individual spaces can be populated in a spaces option:
spaces = [
'MYSPACE',
]
For additional advanced options, refer to the template configuration.
Manual Service Setup
System administrators may manually set up using the following instructions. Adjusts paths to desired preferences.
Build a path to hold packages:
mkdir /opt/sphinx-confluence-relay
cd /opt/sphinx-confluence-relay
Create a virtual environment:
python -m venv .venv
source .venv/bin/activate
Install this service using pip:
pip install sphinx-confluence-relay
Place the prepared configuration file in the local directory with the name:
sphinx-confluence-relay.toml
Run this service:
uvicorn sphinx_confluence_relay.main:app --host 0.0.0.0 --port 8080
Docker
This project supports multiple ways to use this utility inside a Docker environment. A recommended choice is to use a pre-built image available from GitHub's container registry.
Pre-built image
A pre-built image can be acquired using the following command:
docker pull ghcr.io/jdknight/sphinx-confluence-relay
On the host that will run Docker, copy the configuration file into this path:
/etc/sphinx-confluence-relay.toml
Ensure the path is available for holding a database of queued requests and status information:
/var/lib/sphinx-confluence-relay/
The container then can be run using the following command:
docker run --name sphinx-confluence-relay --detach --restart unless-stopped \
-p 8080:8080 \
-v /etc/sphinx-confluence-relay.toml:/etc/sphinx-confluence-relay.toml:ro \
-v /var/lib/sphinx-confluence-relay/database.db:/database.db \
ghcr.io/jdknight/sphinx-confluence-relay
Self-built image
Users who wish to manage their own image can do so with the Docker definitions found inside this repository. This can be done by cloning this repository on the host wanting to run the container. A Docker build can be run using:
docker build -t ghcr.io/jdknight/sphinx-confluence-relay \
--detach -f docker/Dockerfile .
Then running the same docker run call mentioned above.
Self-managed Docker Compose
Users can also take advantage of the Docker compose definition. For a working directory to hold Docker Compose content, ensure a settings file is setup:
sphinx-confluence-relay.toml
Next, load up the container using docker compose:
docker compose build
docker compose up --detach
Both Docker build calls will by default load a container with the
PyPI version of sphinx-confluence-relay. Users wanting to use the local
implementation in their container can do so by performing a Docker build
with the --build-arg local argument.
For example:
docker compose build --build-arg BUILD_MODE=local
docker compose up --detach
Metadata
Release files for sphinx-confluence-relay 0.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| sphinx_confluence_relay-0.2.0.tar.gz | 476.5 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| sphinx_confluence_relay-0.2.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 961.1 kB
Release files / sphinx_confluence_relay-0.2.0.tar.gz
| Download URL | sphinx_confluence_relay-0.2.0.tar.gz |
|---|---|
| Size | 476.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
964d934a998a6f3efa9d446f0c43c71730dfcc572c894bbc8aa303362e897404
|
|
BLAKE2b-256 checksum How to use checksums |
ccc4efad7745f57c22fbfe9ee840ff9b7cd85e1edbbcaa4429e4477f0be89b43
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 20, 2026.
Transparency logRelease files / sphinx_confluence_relay-0.2.0-py3-none-any.whl
| Download URL | sphinx_confluence_relay-0.2.0-py3-none-any.whl |
|---|---|
| Size | 484.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4e0ac544ebe57d34715080ba193a170522ab7394cc46476e0ef6f90ed61055ee
|
|
BLAKE2b-256 checksum How to use checksums |
e07cc48289fdb305490aec9bbdd00b16a21aa3c8b640ae9ae968b3c47dd462e4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 20, 2026.
Transparency logSecurity for sphinx-confluence-relay 0.2.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for sphinx_confluence_relay-0.2.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 20, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.