@helyx/bot 0.4.38 → 0.4.40
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +12 -0
- package/README.md +5 -0
- package/documentation/README.md +49 -0
- package/documentation/examples/.env.example +117 -0
- package/documentation/guides/getting-started.md +98 -0
- package/documentation/guides/privacy-and-support.md +86 -0
- package/documentation/guides/self-hosting.md +90 -0
- package/documentation/modules/building-a-module.md +51 -0
- package/documentation/modules/publishing-a-module.md +33 -0
- package/documentation/modules/testing-a-module.md +52 -0
- package/documentation/reference/environment.md +71 -0
- package/documentation/runbooks/backup-and-recovery.md +62 -0
- package/documentation/runbooks/installation-and-upgrades.md +77 -0
- package/package.json +3 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,17 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.4.40
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- Refresh the packaged public guides and operational documentation shipped with the bot.
|
|
8
|
+
|
|
9
|
+
## 0.4.39
|
|
10
|
+
|
|
11
|
+
### Patch Changes
|
|
12
|
+
|
|
13
|
+
- 38c70f7: Ship maintained public documentation with the bot package and point newly generated self-host projects to its version-matched offline copy.
|
|
14
|
+
|
|
3
15
|
## 0.4.38
|
|
4
16
|
|
|
5
17
|
### Patch Changes
|
package/README.md
CHANGED
|
@@ -2,6 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
The Helyx Discord runtime validates its environment, verifies and migrates PostgreSQL, validates explicitly configured module packages, applies their migrations, composes platform services, synchronises guild installations and commands, logs in with the non-privileged Guilds intent, and shuts down Discord, modules, and PostgreSQL safely.
|
|
4
4
|
|
|
5
|
+
Version-matched public guides, operator runbooks, environment reference
|
|
6
|
+
material, and module-authoring instructions ship at `documentation/README.md`
|
|
7
|
+
inside this npm package. Repository-only `docs/` and `docs-old/` content is not
|
|
8
|
+
published.
|
|
9
|
+
|
|
5
10
|
Command contributions use an explicit registration policy: platform commands
|
|
6
11
|
remain global, migrated customer commands are projected into enabled guilds,
|
|
7
12
|
deployment commands stay with their deployment, and internal commands are
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Helyx public documentation
|
|
2
|
+
|
|
3
|
+
This is the portable, versioned documentation set for Helyx operators and
|
|
4
|
+
module authors. It contains only material intended for public release and ships
|
|
5
|
+
inside the matching `@helyx/bot` npm package.
|
|
6
|
+
|
|
7
|
+
Use the copy shipped with your installed bot when a command, environment value
|
|
8
|
+
or package boundary must match that release. Use
|
|
9
|
+
[docs.helyx.gg](https://docs.helyx.gg/) for the current Hosted Helyx dashboard
|
|
10
|
+
and module guides.
|
|
11
|
+
|
|
12
|
+
## Start here
|
|
13
|
+
|
|
14
|
+
- [Install a self-hosted Helyx instance](guides/getting-started.md)
|
|
15
|
+
- [Understand the self-hosting boundary](guides/self-hosting.md)
|
|
16
|
+
- [Configure the environment](reference/environment.md)
|
|
17
|
+
- [Operate installations and upgrades](runbooks/installation-and-upgrades.md)
|
|
18
|
+
- [Plan backup and recovery](runbooks/backup-and-recovery.md)
|
|
19
|
+
- [Handle privacy and support](guides/privacy-and-support.md)
|
|
20
|
+
- [Build an independent module](modules/building-a-module.md)
|
|
21
|
+
- [Test a module](modules/testing-a-module.md)
|
|
22
|
+
- [Prepare a module package](modules/publishing-a-module.md)
|
|
23
|
+
|
|
24
|
+
The complete working example is published separately as
|
|
25
|
+
`@helyx/module-example`. It is intentionally independent: module-specific
|
|
26
|
+
commands, settings, tests, and lifecycle behaviour remain inside that module.
|
|
27
|
+
|
|
28
|
+
## Choose the right path
|
|
29
|
+
|
|
30
|
+
- **Running the generated starter:** begin with
|
|
31
|
+
[Getting started](guides/getting-started.md), then read the environment,
|
|
32
|
+
backup and upgrade guides before production use.
|
|
33
|
+
- **Operating local data:** read
|
|
34
|
+
[Privacy and support](guides/privacy-and-support.md) and document the provider,
|
|
35
|
+
retention and access controls chosen for your deployment.
|
|
36
|
+
- **Building a module:** start from `@helyx/module-example`, then follow the
|
|
37
|
+
build, test and packaging guides without importing another module's source.
|
|
38
|
+
|
|
39
|
+
## Publication boundary
|
|
40
|
+
|
|
41
|
+
The repository's `docs/` and `docs-old/` trees are internal engineering and
|
|
42
|
+
historical material. They are not part of the bot package. The hosted website
|
|
43
|
+
is also a separate private build workspace. The release process copies only
|
|
44
|
+
this `documentation/` tree into the bot tarball.
|
|
45
|
+
|
|
46
|
+
Do not place credentials, private infrastructure addresses, incident evidence,
|
|
47
|
+
unannounced plans, or internal deployment instructions here. Before a release,
|
|
48
|
+
run `npm run documentation:check` and `npm run release:dry-run` from the Helyx
|
|
49
|
+
repository root.
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
# REQUIRED — EDIT THESE VALUES
|
|
2
|
+
|
|
3
|
+
# Discord
|
|
4
|
+
DISCORD_TOKEN=replace-me
|
|
5
|
+
DISCORD_CLIENT_ID=12345678901234567
|
|
6
|
+
# Explicit privileged gateway opt-in. Keep false unless a reviewed loaded module
|
|
7
|
+
# requires message content and it is enabled in the Discord developer portal.
|
|
8
|
+
HELYX_MESSAGE_CONTENT_ENABLED=false
|
|
9
|
+
# Enable only when member inspection modules are loaded and the Discord Server
|
|
10
|
+
# Members Intent is enabled in the Discord developer portal.
|
|
11
|
+
HELYX_GUILD_MEMBERS_ENABLED=false
|
|
12
|
+
# Database
|
|
13
|
+
# Docker: keep the URL. Direct Node.js/managed hosting: use your provider URL.
|
|
14
|
+
DATABASE_URL=postgresql://database:5432/helyx
|
|
15
|
+
DATABASE_SSL=disable
|
|
16
|
+
|
|
17
|
+
# Included Docker database — both password values must match.
|
|
18
|
+
PGUSER=helyx
|
|
19
|
+
PGPASSWORD=replace-with-a-strong-password
|
|
20
|
+
POSTGRES_DB=helyx
|
|
21
|
+
POSTGRES_USER=helyx
|
|
22
|
+
POSTGRES_PASSWORD=replace-with-a-strong-password
|
|
23
|
+
|
|
24
|
+
# OPTIONAL EVERYDAY SETTINGS
|
|
25
|
+
|
|
26
|
+
# Ready for dashboard linking, but remains unpaired until you use a one-use code.
|
|
27
|
+
HELYX_CLOUD_CONNECT_ENABLED=true
|
|
28
|
+
# Public dashboard origin used in bot-generated report links.
|
|
29
|
+
# HELYX_DASHBOARD_PUBLIC_URL=https://app.helyx.gg
|
|
30
|
+
# HELYX_OWNER_USER_IDS=12345678901234567
|
|
31
|
+
|
|
32
|
+
# trace, debug, info, warn, error, fatal or silent
|
|
33
|
+
LOG_LEVEL=info
|
|
34
|
+
|
|
35
|
+
# Guild-scoped development commands only
|
|
36
|
+
# DISCORD_INTERNAL_GUILD_ID=12345678901234567
|
|
37
|
+
# APPROVED_ROLES=12345678901234567,12345678901234568
|
|
38
|
+
|
|
39
|
+
# SHARDING: OFF BY DEFAULT
|
|
40
|
+
|
|
41
|
+
# `off` is the compatible self-host default. Keep shard-only values commented
|
|
42
|
+
# in this mode; an empty value is still rejected as configured. Advanced local
|
|
43
|
+
# self-hosting may use `auto` to obtain Discord's recommendation under one
|
|
44
|
+
# supervisor, or `fixed` with a deliberate total count. Local mode never needs
|
|
45
|
+
# Redis. Coordinated multi-host self-hosting is outside the first release.
|
|
46
|
+
HELYX_SHARD_MODE=off
|
|
47
|
+
# HELYX_SHARD_SCOPE=local
|
|
48
|
+
# HELYX_SHARD_COUNT=2
|
|
49
|
+
# HELYX_SHARD_WORKERS_PER_REPLICA=2
|
|
50
|
+
# HELYX_SHARD_REDIS_URL=rediss://private-redis.example:6379
|
|
51
|
+
# HELYX_SHARD_REDIS_NAMESPACE=helyx.self-host
|
|
52
|
+
# HELYX_SHARD_GENERATION=local-20260728
|
|
53
|
+
# HELYX_SHARD_DATABASE_CONNECTION_BUDGET=10
|
|
54
|
+
# HELYX_SHARD_SUPERVISOR_DATABASE_POOL_MAX=2
|
|
55
|
+
# HELYX_SHARD_WORKER_DATABASE_POOL_MAX=4
|
|
56
|
+
# Redis URL and namespace are intentionally unsupported for the first
|
|
57
|
+
# self-hosted release: do not uncomment them for local auto or fixed mode.
|
|
58
|
+
|
|
59
|
+
# ADVANCED INTEGRATIONS — EDIT ONLY WHEN NEEDED
|
|
60
|
+
|
|
61
|
+
# Additional reviewed module packages
|
|
62
|
+
# HELYX_MODULE_PACKAGES=
|
|
63
|
+
|
|
64
|
+
# Private dashboard control endpoint — configure both together
|
|
65
|
+
# HELYX_BOT_CONTROL_SECRET=replace-with-a-base64-encoded-32-byte-key
|
|
66
|
+
# HELYX_BOT_CONTROL_PORT=3001
|
|
67
|
+
# HELYX_GUILD_RECONCILIATION_INTERVAL_SECONDS=900
|
|
68
|
+
|
|
69
|
+
# Guild command writes remain off until explicitly enabled for known guild IDs.
|
|
70
|
+
HELYX_GUILD_COMMAND_WRITES_ENABLED=false
|
|
71
|
+
HELYX_GUILD_COMMAND_WRITE_SCOPE=allowlist
|
|
72
|
+
# HELYX_GUILD_COMMAND_RELEASE_ID=
|
|
73
|
+
HELYX_GLOBAL_COMMAND_MODE=legacy
|
|
74
|
+
# HELYX_GUILD_COMMAND_WRITE_GUILD_IDS=
|
|
75
|
+
|
|
76
|
+
# Privacy tooling ships with self-hosted Helyx but stays disabled until the
|
|
77
|
+
# dedicated least-privilege executor connection has been configured.
|
|
78
|
+
HELYX_PRIVACY_ENABLED=false
|
|
79
|
+
# HELYX_PRIVACY_EXECUTOR_DATABASE_URL=<dedicated-privacy-executor-postgresql-url>
|
|
80
|
+
# HELYX_PRIVACY_EXECUTOR_DATABASE_SSL=disable
|
|
81
|
+
|
|
82
|
+
# Alternative Cloud Connect enrolment — the Discord command is preferred
|
|
83
|
+
# HELYX_CLOUD_ENROLMENT_TOKEN=replace-with-a-short-lived-enrolment-code
|
|
84
|
+
# HELYX_CLOUD_ENROLMENT_FILE=./helyx.cloud-enrolment.json
|
|
85
|
+
|
|
86
|
+
# Hosted OAuth bridge. Keep disabled unless the API and bot share this secret.
|
|
87
|
+
HELYX_OAUTH_ENABLED=false
|
|
88
|
+
# HELYX_OAUTH_INTERNAL_SECRET=replace-with-a-base64-encoded-32-byte-key
|
|
89
|
+
|
|
90
|
+
# DANGER ZONE — HELYX-MANAGED VALUES, DO NOT EDIT
|
|
91
|
+
|
|
92
|
+
# Generated module selection
|
|
93
|
+
HELYX_MODULE_CATALOGUE_PATH=./helyx.modules.json
|
|
94
|
+
|
|
95
|
+
# Generated privately by npm run setup. Never change it while Cloud Connect is
|
|
96
|
+
# enrolled or a checkpointed Giveaways draw is in progress.
|
|
97
|
+
# HELYX_DATA_ENCRYPTION_KEY=replace-with-a-base64-encoded-32-byte-key
|
|
98
|
+
|
|
99
|
+
# Official Cloud Connect endpoints
|
|
100
|
+
# HELYX_CLOUD_API_URL=https://api.helyx.gg
|
|
101
|
+
# HELYX_CLOUD_ENDPOINT=wss://connect.helyx.gg/v1/connect
|
|
102
|
+
|
|
103
|
+
# Security audit retention
|
|
104
|
+
# HELYX_CLOUD_AUDIT_RETENTION_DAYS=90
|
|
105
|
+
# HELYX_CLOUD_CREDENTIAL_AUDIT_RETENTION_DAYS=365
|
|
106
|
+
|
|
107
|
+
# Optional public status reporting. Keep disabled unless this installation has
|
|
108
|
+
# its own approved Helyx status credentials.
|
|
109
|
+
HELYX_STATUS_ENABLED=false
|
|
110
|
+
# HELYX_STATUS_URL=https://status.helyx.gg
|
|
111
|
+
# HELYX_STATUS_HEARTBEAT_SECRET=replace-with-a-base64-encoded-32-byte-key
|
|
112
|
+
# HELYX_STATUS_HEARTBEAT_INTERVAL_SECONDS=60
|
|
113
|
+
# CF_ACCESS_CLIENT_ID=replace-with-access-client-id
|
|
114
|
+
# CF_ACCESS_CLIENT_SECRET=replace-with-access-client-secret
|
|
115
|
+
|
|
116
|
+
# Runtime mode
|
|
117
|
+
NODE_ENV=production
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Getting started with self-hosted Helyx
|
|
2
|
+
|
|
3
|
+
Use this guide to generate a reviewed Helyx Self-Hosted project, validate its
|
|
4
|
+
configuration and prove one module works in a private Discord server.
|
|
5
|
+
|
|
6
|
+
> **Availability:** use the builder as the source of truth. If it does not offer
|
|
7
|
+
> a starter or manifest download, no production Helyx Self-Hosted release is
|
|
8
|
+
> available through the supported flow. Do not assemble one by installing
|
|
9
|
+
> packages manually.
|
|
10
|
+
|
|
11
|
+
## Requirements
|
|
12
|
+
|
|
13
|
+
- Node.js 24 or 26 and npm 11 or later.
|
|
14
|
+
- A Discord application and bot token.
|
|
15
|
+
- PostgreSQL with a database you can back up and restore.
|
|
16
|
+
- Permission to install the bot in the Discord servers you manage.
|
|
17
|
+
|
|
18
|
+
Keep the bot token, database credentials, encryption keys, and control secrets
|
|
19
|
+
outside source control.
|
|
20
|
+
|
|
21
|
+
## Create the project
|
|
22
|
+
|
|
23
|
+
The simplest path is to sign in at
|
|
24
|
+
[app.helyx.gg/self-host](https://app.helyx.gg/self-host), choose the Live
|
|
25
|
+
modules you need and download a complete starter ZIP. Extract it into a new
|
|
26
|
+
private directory and read its generated `README.md`.
|
|
27
|
+
|
|
28
|
+
For scripted generation, download a build manifest from the same builder and
|
|
29
|
+
use the current CLI:
|
|
30
|
+
|
|
31
|
+
```sh
|
|
32
|
+
npx --yes @helyx/cli@latest self-host init --manifest ./helyx-build.json --output ./helyx --install
|
|
33
|
+
cd helyx
|
|
34
|
+
npm run setup
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
`helyx setup` creates `.env` from `.env.example` only when `.env` does not
|
|
38
|
+
already exist. Edit the required Discord and database values before continuing.
|
|
39
|
+
See the [environment reference](../reference/environment.md).
|
|
40
|
+
|
|
41
|
+
## Validate before Discord sign-in
|
|
42
|
+
|
|
43
|
+
```sh
|
|
44
|
+
npm run doctor
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
The doctor checks configuration, PostgreSQL connectivity, migration history,
|
|
48
|
+
and installed module metadata without logging in to Discord or changing the
|
|
49
|
+
database. Correct every reported error before starting.
|
|
50
|
+
|
|
51
|
+
## Start Helyx
|
|
52
|
+
|
|
53
|
+
```sh
|
|
54
|
+
npm start
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
For a long-running host, use the service or container supervision provided by
|
|
58
|
+
your operating system or hosting platform. Configure automatic restarts with a
|
|
59
|
+
bounded delay, retain logs without secrets, and arrange database backups before
|
|
60
|
+
inviting production traffic.
|
|
61
|
+
|
|
62
|
+
## Complete the Discord setup
|
|
63
|
+
|
|
64
|
+
1. Create or select an application in the Discord Developer Portal and add its
|
|
65
|
+
bot user.
|
|
66
|
+
2. Put the application ID and bot token in the protected environment.
|
|
67
|
+
3. Add the bot with the `bot` and `applications.commands` scopes.
|
|
68
|
+
4. Grant only the Discord permissions required by selected modules; Helyx core
|
|
69
|
+
does not require Administrator.
|
|
70
|
+
5. Start Helyx and wait for its ready result.
|
|
71
|
+
6. Run `/helyx modules` in a private test server where you can manage Helyx.
|
|
72
|
+
7. Enable and configure one installed module, then restart once to confirm its
|
|
73
|
+
saved state remains available.
|
|
74
|
+
|
|
75
|
+
Installing a module package and enabling its feature for a Discord server are
|
|
76
|
+
separate actions. Installed customer modules start disabled.
|
|
77
|
+
|
|
78
|
+
## Troubleshooting
|
|
79
|
+
|
|
80
|
+
### Doctor cannot reach PostgreSQL
|
|
81
|
+
|
|
82
|
+
Check the connection URL, credentials, network allowlist and `DATABASE_SSL`
|
|
83
|
+
against the provider's instructions. Do not paste the URL into a support
|
|
84
|
+
request.
|
|
85
|
+
|
|
86
|
+
### The bot starts but a module is unavailable
|
|
87
|
+
|
|
88
|
+
Confirm the package appears in `helyx.modules.json`, its installed metadata
|
|
89
|
+
passes `npm run doctor` and it is enabled for that Discord server.
|
|
90
|
+
|
|
91
|
+
### Helyx cannot act on a channel or role
|
|
92
|
+
|
|
93
|
+
Check the exact channel/category overrides and place Helyx's role above roles
|
|
94
|
+
it must manage. Administrator is optional and should not be used to hide a
|
|
95
|
+
narrow permission or hierarchy problem.
|
|
96
|
+
|
|
97
|
+
Next read the [self-hosting guide](self-hosting.md) and the
|
|
98
|
+
[installation and upgrade runbook](../runbooks/installation-and-upgrades.md).
|
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
# Privacy and support for Helyx Self-Hosted
|
|
2
|
+
|
|
3
|
+
Use this guide to separate locally controlled records from Helyx-hosted data,
|
|
4
|
+
route a request to the correct owner and ask for help without exposing secrets.
|
|
5
|
+
|
|
6
|
+
## Identify who controls the record
|
|
7
|
+
|
|
8
|
+
- **Local Helyx Self-Hosted data:** the deployment owner controls the local
|
|
9
|
+
PostgreSQL database, module records, logs and backups.
|
|
10
|
+
- **Cloud Connect and Helyx account data:** Helyx controls the bounded hosted
|
|
11
|
+
installation, session, support and connector records it receives.
|
|
12
|
+
- **Discord data:** Discord controls platform messages, roles, channels and
|
|
13
|
+
account records separately.
|
|
14
|
+
|
|
15
|
+
Cloud Connect does not provide Helyx with unrestricted access to the local
|
|
16
|
+
database. A request submitted to the Helyx Privacy Centre therefore does not
|
|
17
|
+
automatically reach local-only records.
|
|
18
|
+
|
|
19
|
+
## Handle a local request
|
|
20
|
+
|
|
21
|
+
1. Confirm the requester through an authorised route without asking them to
|
|
22
|
+
send a password, token or unrelated identity document.
|
|
23
|
+
2. Record the request scope and the exact local deployment concerned.
|
|
24
|
+
3. Identify the module providers and local operational records that can contain
|
|
25
|
+
the subject's Discord user ID.
|
|
26
|
+
4. Preserve another person's data, required security evidence and auditable
|
|
27
|
+
server actions while applying the supported access, correction, restriction
|
|
28
|
+
or deletion operation.
|
|
29
|
+
5. Include active data and backups in the deployment's documented retention
|
|
30
|
+
process.
|
|
31
|
+
6. Record the outcome without copying unnecessary personal data into support
|
|
32
|
+
logs.
|
|
33
|
+
|
|
34
|
+
Self-host privacy tooling ships disabled until its dedicated least-privilege
|
|
35
|
+
executor connection is configured. Do not grant the normal bot or a support
|
|
36
|
+
account unrestricted database access as a shortcut.
|
|
37
|
+
|
|
38
|
+
## Use the Helyx Privacy Centre
|
|
39
|
+
|
|
40
|
+
For records held by Helyx, use
|
|
41
|
+
[app.helyx.gg/privacy](https://app.helyx.gg/privacy). If Discord sign-in is
|
|
42
|
+
unavailable, email `privacy@helyx.gg`. The central workflow can prepare an
|
|
43
|
+
access export, start erasure with a seven-day cancellation period, accept a
|
|
44
|
+
display-name correction or route a restriction, objection, portability request
|
|
45
|
+
or complaint for review.
|
|
46
|
+
|
|
47
|
+
## Contact support safely
|
|
48
|
+
|
|
49
|
+
For an ordinary product or Self-Hosted question, open
|
|
50
|
+
[Helyx Support](https://app.helyx.gg/support). Include the installed Helyx and
|
|
51
|
+
module versions, safe error text, approximate time with timezone, expected
|
|
52
|
+
result and repeatable steps.
|
|
53
|
+
|
|
54
|
+
Never include:
|
|
55
|
+
|
|
56
|
+
- `.env` or a database URL;
|
|
57
|
+
- Discord, OAuth, Cloud Connect or status credentials;
|
|
58
|
+
- the data-encryption key;
|
|
59
|
+
- database dumps or unrestricted logs; or
|
|
60
|
+
- unrelated member content.
|
|
61
|
+
|
|
62
|
+
For a repeatable product fault, use
|
|
63
|
+
[Report a bug](https://app.helyx.gg/report-bug). For a suspected vulnerability,
|
|
64
|
+
use the [private security route](https://helyx.gg/security/) and follow its safe
|
|
65
|
+
testing rules. Modified source, unsupported package combinations and provider
|
|
66
|
+
administration remain outside the normal generated-project support boundary.
|
|
67
|
+
|
|
68
|
+
## Troubleshooting
|
|
69
|
+
|
|
70
|
+
### The central export does not contain a local record
|
|
71
|
+
|
|
72
|
+
This is expected when the record exists only in the deployment owner's
|
|
73
|
+
PostgreSQL database. Contact that owner and follow the local request process.
|
|
74
|
+
|
|
75
|
+
### A support reply asks for more evidence
|
|
76
|
+
|
|
77
|
+
Provide the smallest redacted item that answers the question. Do not transmit a
|
|
78
|
+
secret or complete database dump; ask for an authorised route if a file is
|
|
79
|
+
genuinely required.
|
|
80
|
+
|
|
81
|
+
## Related guides
|
|
82
|
+
|
|
83
|
+
- [Self-hosting responsibilities](self-hosting.md)
|
|
84
|
+
- [Environment reference](../reference/environment.md)
|
|
85
|
+
- [Backup and recovery](../runbooks/backup-and-recovery.md)
|
|
86
|
+
- [Online Helyx data guides](https://docs.helyx.gg/your-data/)
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
# Self-hosting responsibilities
|
|
2
|
+
|
|
3
|
+
Self-hosting gives you control of the Helyx runtime and its data. It also makes
|
|
4
|
+
you responsible for the host, PostgreSQL, Discord credentials, environment
|
|
5
|
+
configuration, updates, monitoring, backups, and recovery testing.
|
|
6
|
+
|
|
7
|
+
## Supported shape
|
|
8
|
+
|
|
9
|
+
A normal installation contains one generated Helyx project, one PostgreSQL
|
|
10
|
+
database, the reviewed core packages, and independently selected modules. Keep
|
|
11
|
+
module boundaries intact: a module must be installable, configurable, testable,
|
|
12
|
+
and removable without relying on unrelated module behaviour.
|
|
13
|
+
|
|
14
|
+
Helyx supports Docker Compose and direct Node.js operation. The generated
|
|
15
|
+
project is the source of truth for its pinned public packages and module
|
|
16
|
+
catalogue. Do not copy source trees from the Helyx repository into an
|
|
17
|
+
installation.
|
|
18
|
+
|
|
19
|
+
## Secrets and access
|
|
20
|
+
|
|
21
|
+
- Store `.env` outside version control and restrict who can read it.
|
|
22
|
+
- Use a dedicated database user and the least privileges supported by your
|
|
23
|
+
deployment.
|
|
24
|
+
- Rotate a Discord token or control secret if it may have been exposed.
|
|
25
|
+
- Do not paste secret values into logs, issues, screenshots, or support chats.
|
|
26
|
+
- Limit network access to PostgreSQL and private control endpoints.
|
|
27
|
+
|
|
28
|
+
## Operating baseline
|
|
29
|
+
|
|
30
|
+
- Run `npm run doctor` after configuration or package changes.
|
|
31
|
+
- Watch process health, database capacity, command deployment errors, and module
|
|
32
|
+
health.
|
|
33
|
+
- Back up both PostgreSQL and the environment or key material needed to decrypt
|
|
34
|
+
its records.
|
|
35
|
+
- Test recovery in a disposable environment.
|
|
36
|
+
- Apply compatible releases as one reviewed set; do not upgrade internal Helyx
|
|
37
|
+
packages independently.
|
|
38
|
+
|
|
39
|
+
Cloud Connect is optional. Enabling it does not transfer responsibility for the
|
|
40
|
+
self-hosted process, database, secrets, or backups to Helyx.
|
|
41
|
+
|
|
42
|
+
Cloud Connect enrolment is available only when the dashboard offers the
|
|
43
|
+
one-use-code control for a compatible release. Setting the local environment
|
|
44
|
+
switch does not make an unavailable hosted service available.
|
|
45
|
+
|
|
46
|
+
## Cloud Connect boundary
|
|
47
|
+
|
|
48
|
+
Generated configuration is ready for Cloud Connect by default but remains
|
|
49
|
+
unpaired. A configured deployment owner or Discord application owner or team
|
|
50
|
+
member creates a one-use code in the Helyx dashboard and enters it with
|
|
51
|
+
`/helyx cloud connect`. Check the result with `/helyx cloud status`.
|
|
52
|
+
|
|
53
|
+
The connector sends bounded capabilities, health and dashboard
|
|
54
|
+
request/response data over an outbound authenticated connection. It does not
|
|
55
|
+
send the Discord token, database URL or data-encryption key. Local Discord
|
|
56
|
+
features continue if the hosted dashboard is temporarily unavailable.
|
|
57
|
+
|
|
58
|
+
Set `HELYX_CLOUD_CONNECT_ENABLED=false` before startup when the installation
|
|
59
|
+
must remain entirely local.
|
|
60
|
+
|
|
61
|
+
## Before production use
|
|
62
|
+
|
|
63
|
+
1. Prove `npm run doctor` from the production environment.
|
|
64
|
+
2. Test one stateful module in a private server.
|
|
65
|
+
3. Restart the process and confirm settings remain available.
|
|
66
|
+
4. Create and test a PostgreSQL restore in a disposable environment.
|
|
67
|
+
5. Record package versions, log access, monitoring and the responsible owner.
|
|
68
|
+
6. Document how local data access, correction, restriction and deletion will be
|
|
69
|
+
handled.
|
|
70
|
+
|
|
71
|
+
## Troubleshooting
|
|
72
|
+
|
|
73
|
+
### Cloud Connect cannot decrypt its local identity
|
|
74
|
+
|
|
75
|
+
Restore the original `HELYX_DATA_ENCRYPTION_KEY`. If it cannot be recovered,
|
|
76
|
+
revoke the old installation in the dashboard and enrol a new identity with a
|
|
77
|
+
fresh one-use code.
|
|
78
|
+
|
|
79
|
+
### A hosting provider cannot run the starter
|
|
80
|
+
|
|
81
|
+
The provider must support the release's Node.js and npm versions, run
|
|
82
|
+
`npm start`, preserve protected environment values and reach PostgreSQL. A
|
|
83
|
+
provider that cannot meet those requirements is not a supported runtime path.
|
|
84
|
+
|
|
85
|
+
## Related guides
|
|
86
|
+
|
|
87
|
+
- [Getting started](getting-started.md)
|
|
88
|
+
- [Environment reference](../reference/environment.md)
|
|
89
|
+
- [Backup and recovery](../runbooks/backup-and-recovery.md)
|
|
90
|
+
- [Privacy and support](privacy-and-support.md)
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Building an independent Helyx module
|
|
2
|
+
|
|
3
|
+
Start from the published `@helyx/module-example` package. It contains a
|
|
4
|
+
self-contained TypeScript project, manifest, source, tests, and packaging
|
|
5
|
+
allowlist that can be copied into a new repository or workspace.
|
|
6
|
+
|
|
7
|
+
## Before you begin
|
|
8
|
+
|
|
9
|
+
- Use Node.js `>=24 <27` and npm `>=11`.
|
|
10
|
+
- Choose a unique package name and module ID.
|
|
11
|
+
- Decide whether the module is one independently useful feature; do not combine
|
|
12
|
+
unrelated functions to reduce file count.
|
|
13
|
+
- Choose and state the licence that will govern your independent module.
|
|
14
|
+
|
|
15
|
+
## Required parts
|
|
16
|
+
|
|
17
|
+
Every module needs:
|
|
18
|
+
|
|
19
|
+
- a unique npm package name and semantic version;
|
|
20
|
+
- a Helyx module manifest parsed by `@helyx/module-manifest`;
|
|
21
|
+
- a default JavaScript export created with `defineModule` from `@helyx/sdk`;
|
|
22
|
+
- explicit `start` and `stop` lifecycle functions;
|
|
23
|
+
- a privacy declaration and provider, including when no personal data is held;
|
|
24
|
+
- compiled JavaScript and declarations matching the package exports;
|
|
25
|
+
- tests for manifest parity, loading, lifecycle behaviour, and each declared
|
|
26
|
+
contribution.
|
|
27
|
+
|
|
28
|
+
Dashboard fields need matching configuration validation. Manifest command IDs
|
|
29
|
+
must exactly match executable command contributions. Declare Discord
|
|
30
|
+
permissions and privileged capabilities only when the module actually needs
|
|
31
|
+
them.
|
|
32
|
+
|
|
33
|
+
## Preserve modularity
|
|
34
|
+
|
|
35
|
+
A module owns its commands, configuration, data, migrations, health, and tests.
|
|
36
|
+
Do not merge unrelated features into one module merely to share code. Put
|
|
37
|
+
reusable contracts in a support package when necessary, and keep each module
|
|
38
|
+
independently installable and usable.
|
|
39
|
+
|
|
40
|
+
Do not import private Helyx applications, another module's source files, or
|
|
41
|
+
repository-relative configuration. Depend only on published packages with
|
|
42
|
+
compatible version ranges. Module behaviour must fail clearly when an optional
|
|
43
|
+
external service is unavailable.
|
|
44
|
+
|
|
45
|
+
See [testing a module](testing-a-module.md) before adding product behaviour.
|
|
46
|
+
|
|
47
|
+
## Related guides
|
|
48
|
+
|
|
49
|
+
- [Test a module](testing-a-module.md)
|
|
50
|
+
- [Prepare a module for npm](publishing-a-module.md)
|
|
51
|
+
- [`@helyx/module-example` on npm](https://www.npmjs.com/package/@helyx/module-example)
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Preparing a module for npm
|
|
2
|
+
|
|
3
|
+
This checklist prepares a package for review. It does not authorize publishing
|
|
4
|
+
to npm or adding a module to the official Helyx catalogue.
|
|
5
|
+
|
|
6
|
+
1. Choose a unique package name and keep the package version equal to the
|
|
7
|
+
manifest version.
|
|
8
|
+
2. Use compatible ranges for `@helyx/module-manifest` and `@helyx/sdk`.
|
|
9
|
+
3. Compile to `dist/` and expose both a JavaScript default entry and a `.d.ts`
|
|
10
|
+
declaration entry.
|
|
11
|
+
4. Use an explicit `files` allowlist. Exclude source maps and TypeScript build
|
|
12
|
+
caches.
|
|
13
|
+
5. Include `manifest.json`, `README.md`, `CHANGELOG.md`, and the licence that
|
|
14
|
+
applies to your code.
|
|
15
|
+
6. Run the complete test suite and `npm pack --dry-run` from a clean checkout.
|
|
16
|
+
7. Extract the generated tarball into a temporary project and import its default
|
|
17
|
+
export under a supported Node.js version.
|
|
18
|
+
8. Search the packed file list for `.env`, credentials, private URLs, logs,
|
|
19
|
+
dumps, tests with fixtures containing real data, and repository-only notes.
|
|
20
|
+
|
|
21
|
+
Third-party modules choose and clearly state their own licence. Do not copy the
|
|
22
|
+
Helyx Source Available Licence notice into a third-party module unless that
|
|
23
|
+
licence actually governs the module.
|
|
24
|
+
|
|
25
|
+
Publishing a package does not make it an official or reviewed Helyx module.
|
|
26
|
+
Catalogue inclusion, security review, permissions, privacy declarations, and
|
|
27
|
+
release support are separate decisions.
|
|
28
|
+
|
|
29
|
+
## Related guides
|
|
30
|
+
|
|
31
|
+
- [Build an independent module](building-a-module.md)
|
|
32
|
+
- [Test a module](testing-a-module.md)
|
|
33
|
+
- [`@helyx/module-example` on npm](https://www.npmjs.com/package/@helyx/module-example)
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Testing a Helyx module
|
|
2
|
+
|
|
3
|
+
The `@helyx/module-example` suite demonstrates four compatibility layers.
|
|
4
|
+
|
|
5
|
+
## Manifest and export
|
|
6
|
+
|
|
7
|
+
Parse `manifest.json`, import the module's default export, and assert that the
|
|
8
|
+
runtime manifest equals the packaged manifest. This prevents metadata from
|
|
9
|
+
drifting away from executable contributions.
|
|
10
|
+
|
|
11
|
+
## Lifecycle
|
|
12
|
+
|
|
13
|
+
Call `start`, `health`, and `stop` with a minimal SDK runtime context. Verify
|
|
14
|
+
observable behaviour and make both lifecycle functions safe for the runtime to
|
|
15
|
+
call. Do not start network listeners or timers at import time.
|
|
16
|
+
|
|
17
|
+
## Dashboard
|
|
18
|
+
|
|
19
|
+
Parse the complete manifest with `@helyx/module-manifest`. Test valid defaults,
|
|
20
|
+
boundary values, wrong types, and missing required settings against the
|
|
21
|
+
module's configuration contribution. Each dashboard setting key must have one
|
|
22
|
+
matching validator field.
|
|
23
|
+
|
|
24
|
+
## Slash commands
|
|
25
|
+
|
|
26
|
+
Assert that manifest command IDs and executable command names are identical.
|
|
27
|
+
Build the command with the same Discord.js builders used by Helyx, inspect the
|
|
28
|
+
generated application-command payload, and execute the handler with a fake SDK
|
|
29
|
+
context. Test acknowledgement, context, integration type, option limits, and a
|
|
30
|
+
representative response without contacting Discord.
|
|
31
|
+
|
|
32
|
+
## Before packaging
|
|
33
|
+
|
|
34
|
+
Run the module's build and test scripts, then inspect exactly what npm would
|
|
35
|
+
include:
|
|
36
|
+
|
|
37
|
+
```sh
|
|
38
|
+
npm run build
|
|
39
|
+
npm test
|
|
40
|
+
npm pack --dry-run
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
The tarball needs compiled exports, declarations, the manifest, instructions,
|
|
44
|
+
licence, and any source or tests deliberately offered as a template. It must
|
|
45
|
+
not contain credentials, logs, source maps, build caches, or internal Helyx
|
|
46
|
+
documentation.
|
|
47
|
+
|
|
48
|
+
## Related guides
|
|
49
|
+
|
|
50
|
+
- [Build an independent module](building-a-module.md)
|
|
51
|
+
- [Prepare a module for npm](publishing-a-module.md)
|
|
52
|
+
- [`@helyx/module-example` on npm](https://www.npmjs.com/package/@helyx/module-example)
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# Environment reference
|
|
2
|
+
|
|
3
|
+
Start from [the published example](../examples/.env.example). The example is a
|
|
4
|
+
copy of the starter emitted by the supported CLI and is checked for drift.
|
|
5
|
+
|
|
6
|
+
This page explains the ownership and safe defaults of the generated variables;
|
|
7
|
+
the comments in `.env.example` remain the version-matched field reference.
|
|
8
|
+
|
|
9
|
+
## Required values
|
|
10
|
+
|
|
11
|
+
`DISCORD_TOKEN` is the bot token from the Discord developer portal.
|
|
12
|
+
`DISCORD_CLIENT_ID` is the application's numeric ID. `DATABASE_URL` points to
|
|
13
|
+
PostgreSQL; `DATABASE_SSL` must match the database provider. Docker users must
|
|
14
|
+
also replace the example PostgreSQL password consistently in `PGPASSWORD` and
|
|
15
|
+
`POSTGRES_PASSWORD`.
|
|
16
|
+
|
|
17
|
+
## Safe defaults
|
|
18
|
+
|
|
19
|
+
Privileged Discord intents, privacy execution, hosted OAuth, status reporting,
|
|
20
|
+
guild command writes, and advanced sharding stay disabled until their complete
|
|
21
|
+
requirements are deliberately configured. An empty variable still counts as a
|
|
22
|
+
configured value in many environments, so leave unused optional lines
|
|
23
|
+
commented.
|
|
24
|
+
|
|
25
|
+
`HELYX_CLOUD_CONNECT_ENABLED=true` makes an installation ready to be paired; it
|
|
26
|
+
does not pair the installation by itself. Keep official endpoint overrides
|
|
27
|
+
commented unless Helyx support directs otherwise.
|
|
28
|
+
|
|
29
|
+
## Generated values
|
|
30
|
+
|
|
31
|
+
The CLI owns `HELYX_MODULE_CATALOGUE_PATH` and may generate
|
|
32
|
+
`HELYX_DATA_ENCRYPTION_KEY`. Preserve generated key material for the lifetime of
|
|
33
|
+
the encrypted data. Losing it can make records unrecoverable; replacing it is
|
|
34
|
+
not a password reset.
|
|
35
|
+
|
|
36
|
+
## Verification
|
|
37
|
+
|
|
38
|
+
After every environment change, run:
|
|
39
|
+
|
|
40
|
+
```sh
|
|
41
|
+
npm run doctor
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Never include the real `.env` file in an npm package, container image layer,
|
|
45
|
+
source archive, or support bundle.
|
|
46
|
+
|
|
47
|
+
## Common failures
|
|
48
|
+
|
|
49
|
+
### A variable is present but still rejected
|
|
50
|
+
|
|
51
|
+
An empty environment variable counts as configured in many hosts. Remove
|
|
52
|
+
unused optional values instead of setting them to an empty string. Replace all
|
|
53
|
+
required placeholders with real protected values.
|
|
54
|
+
|
|
55
|
+
### PostgreSQL works locally but not on the host
|
|
56
|
+
|
|
57
|
+
Check network access and `DATABASE_SSL` using the database provider's required
|
|
58
|
+
mode. The Docker default is for the included private container network and must
|
|
59
|
+
not be copied blindly to an Internet database.
|
|
60
|
+
|
|
61
|
+
### Encrypted records fail after deployment
|
|
62
|
+
|
|
63
|
+
Restore the original `HELYX_DATA_ENCRYPTION_KEY`. Generate it once and preserve
|
|
64
|
+
it; replacing it is not a password reset.
|
|
65
|
+
|
|
66
|
+
## Related guides
|
|
67
|
+
|
|
68
|
+
- [Getting started](../guides/getting-started.md)
|
|
69
|
+
- [Self-hosting responsibilities](../guides/self-hosting.md)
|
|
70
|
+
- [Backup and recovery](../runbooks/backup-and-recovery.md)
|
|
71
|
+
- [Privacy and support](../guides/privacy-and-support.md)
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Backup and recovery runbook
|
|
2
|
+
|
|
3
|
+
A usable Helyx backup includes PostgreSQL plus the environment and generated
|
|
4
|
+
key material required to read encrypted records. A copy of the generated
|
|
5
|
+
project without its database is not a complete backup.
|
|
6
|
+
|
|
7
|
+
## Back up
|
|
8
|
+
|
|
9
|
+
1. Record the installed package lockfile and Helyx release versions.
|
|
10
|
+
2. Create a consistent PostgreSQL backup with your database provider or
|
|
11
|
+
PostgreSQL tooling.
|
|
12
|
+
3. Back up `.env` and generated enrollment or encryption material separately.
|
|
13
|
+
4. Encrypt backups, restrict access, and store at least one copy away from the
|
|
14
|
+
running host.
|
|
15
|
+
5. Apply a documented retention schedule to both active and backup data.
|
|
16
|
+
|
|
17
|
+
Never commit a database dump or real environment file to Git and never place it
|
|
18
|
+
inside an npm package.
|
|
19
|
+
|
|
20
|
+
## Test recovery
|
|
21
|
+
|
|
22
|
+
At a regular interval:
|
|
23
|
+
|
|
24
|
+
1. Create a disposable network and a separate empty database.
|
|
25
|
+
2. Restore a selected backup without overwriting production.
|
|
26
|
+
3. Restore the matching environment and key material through the host's secret
|
|
27
|
+
mechanism.
|
|
28
|
+
4. Run `npm ci` and `npm run doctor`.
|
|
29
|
+
5. Confirm a stateful module can read its configuration and records.
|
|
30
|
+
6. Destroy the disposable environment using the same controls as production.
|
|
31
|
+
|
|
32
|
+
Record the recovery time, the backup generation used, the checks performed,
|
|
33
|
+
and any corrective action. Treat restored data with the same access controls
|
|
34
|
+
and deletion obligations as production data.
|
|
35
|
+
|
|
36
|
+
## Incident recovery
|
|
37
|
+
|
|
38
|
+
Stop writes before a destructive restore. Preserve evidence needed to
|
|
39
|
+
understand the incident, select a known-good backup, restore into a new database
|
|
40
|
+
when possible, validate it, then deliberately switch the runtime. Do not test a
|
|
41
|
+
restore over the only production database.
|
|
42
|
+
|
|
43
|
+
## Troubleshooting
|
|
44
|
+
|
|
45
|
+
### PostgreSQL restored but Cloud Connect or protected records fail
|
|
46
|
+
|
|
47
|
+
Confirm the restored runtime uses the matching data-encryption key and any
|
|
48
|
+
generated enrolment material. Do not replace the key or delete affected rows to
|
|
49
|
+
hide the mismatch.
|
|
50
|
+
|
|
51
|
+
### Doctor reports a migration checksum mismatch
|
|
52
|
+
|
|
53
|
+
Restore the reviewed package files that supplied the migration. Never edit an
|
|
54
|
+
applied migration or its history. Preserve the safe migration name and checksum
|
|
55
|
+
for support.
|
|
56
|
+
|
|
57
|
+
## Related guides
|
|
58
|
+
|
|
59
|
+
- [Environment reference](../reference/environment.md)
|
|
60
|
+
- [Installation and upgrades](installation-and-upgrades.md)
|
|
61
|
+
- [Self-hosting responsibilities](../guides/self-hosting.md)
|
|
62
|
+
- [Privacy and support](../guides/privacy-and-support.md)
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# Installation and upgrade runbook
|
|
2
|
+
|
|
3
|
+
Use this runbook for the first start of a generated project and for a reviewed
|
|
4
|
+
release-set update that preserves the local environment and database.
|
|
5
|
+
|
|
6
|
+
## First installation
|
|
7
|
+
|
|
8
|
+
1. Generate the project with `helyx self-host init` and a reviewed build
|
|
9
|
+
manifest.
|
|
10
|
+
2. Copy and complete `.env` with `helyx setup`.
|
|
11
|
+
3. Install dependencies with `npm ci` if they were not installed during
|
|
12
|
+
generation.
|
|
13
|
+
4. Run `npm run doctor` and resolve every error.
|
|
14
|
+
5. Start the process and confirm database, Discord, and module health.
|
|
15
|
+
6. Exercise one low-risk command in a test server before production use.
|
|
16
|
+
|
|
17
|
+
## Upgrade
|
|
18
|
+
|
|
19
|
+
1. Read the release notes and confirm the supported Node.js and npm versions.
|
|
20
|
+
2. Create a current PostgreSQL backup and preserve the existing project
|
|
21
|
+
metadata and environment file.
|
|
22
|
+
3. Stop the Helyx process cleanly.
|
|
23
|
+
4. Preview the compatible release set:
|
|
24
|
+
|
|
25
|
+
```sh
|
|
26
|
+
helyx self-host update --check
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
5. Apply it only after reviewing the complete change:
|
|
30
|
+
|
|
31
|
+
```sh
|
|
32
|
+
helyx self-host update --confirm
|
|
33
|
+
npm ci
|
|
34
|
+
npm run doctor
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
6. Start Helyx and verify health, command availability, and one representative
|
|
38
|
+
workflow for every upgraded module.
|
|
39
|
+
|
|
40
|
+
The updater backs up managed project metadata under `.helyx/backups` and does
|
|
41
|
+
not change `.env` or customer database data. Database migrations can be
|
|
42
|
+
forward-only. Never edit migration history or downgrade individual Helyx
|
|
43
|
+
packages to simulate a rollback.
|
|
44
|
+
|
|
45
|
+
## Failed validation
|
|
46
|
+
|
|
47
|
+
Leave the process stopped, retain sanitised logs, and determine whether the
|
|
48
|
+
failure is configuration, package integrity, database connectivity, or module
|
|
49
|
+
compatibility. If the updater restored managed files, rerun `npm ci` and
|
|
50
|
+
`npm run doctor` before restarting the previous version. Restore data only from
|
|
51
|
+
a tested backup and only when the incident specifically requires it.
|
|
52
|
+
|
|
53
|
+
## Troubleshooting
|
|
54
|
+
|
|
55
|
+
### The updater reports an incompatible module
|
|
56
|
+
|
|
57
|
+
Keep the current working release set. Do not update core, CLI or modules
|
|
58
|
+
independently. Return to the Helyx Self-Hosted builder, keep every current
|
|
59
|
+
module selected and review which compatible set is available.
|
|
60
|
+
|
|
61
|
+
### The previous managed files were restored
|
|
62
|
+
|
|
63
|
+
Leave the bot stopped. Run `npm ci` and `npm run doctor` against the restored
|
|
64
|
+
metadata. Restart the previous version only after doctor succeeds; restore data
|
|
65
|
+
only when a tested compatible backup is specifically required.
|
|
66
|
+
|
|
67
|
+
### A newly installed package is not available in Discord
|
|
68
|
+
|
|
69
|
+
Confirm it is included in `helyx.modules.json` and enabled for that Discord
|
|
70
|
+
server. Package installation and per-server module activation are separate.
|
|
71
|
+
|
|
72
|
+
## Related guides
|
|
73
|
+
|
|
74
|
+
- [Getting started](../guides/getting-started.md)
|
|
75
|
+
- [Environment reference](../reference/environment.md)
|
|
76
|
+
- [Backup and recovery](backup-and-recovery.md)
|
|
77
|
+
- [Privacy and support](../guides/privacy-and-support.md)
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@helyx/bot",
|
|
3
|
-
"version": "0.4.
|
|
3
|
+
"version": "0.4.40",
|
|
4
4
|
"description": "Production Discord runtime for the modular Helyx platform.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"helyx",
|
|
@@ -32,6 +32,7 @@
|
|
|
32
32
|
"dist",
|
|
33
33
|
"!dist/*.tsbuildinfo",
|
|
34
34
|
"!dist/**/*.map",
|
|
35
|
+
"documentation",
|
|
35
36
|
"CHANGELOG.md",
|
|
36
37
|
"README.md",
|
|
37
38
|
"LICENSE"
|
|
@@ -44,6 +45,7 @@
|
|
|
44
45
|
},
|
|
45
46
|
"scripts": {
|
|
46
47
|
"build": "tsc -b",
|
|
48
|
+
"prepack": "node ../../scripts/public-documentation.mjs --sync-bot",
|
|
47
49
|
"dev": "node --env-file-if-exists=../../.env --import tsx src/index.ts",
|
|
48
50
|
"start": "node --env-file-if-exists=../../.env dist/index.js"
|
|
49
51
|
},
|