MiroTalk SFU: Recording not possible?

[MiroTalk]

Previously, I was using a relative path, but now I’ll switch to an absolute path. This means the recordings can also be stored directly on the server in /root/rec.

The .env file would look like this:

RECORDING_ENABLED=true
RECORDING_DIR='/root/rec'   # Absolute path for recordings

Similarly, for RTMP stream read from file:

RTMP_DIR='/root/rtmp'       # Absolute path for RTMP file streams

But agree, this needs to be tested well.

[MiroTalk]

There are some cons to consider

Absolute Path:
Cons:

• Less portable, if you move the project to another server or directory, the path may break.
• Hard-coded paths can be less flexible.

Relative Path:
Pros:

• Portable, works anywhere as long as the folder structure relative to your project stays the same.
• Easier for development and version control.

I’m not entirely sure if switching to an absolute path is the best approach, maybe this could be handled on the Cloudron side instead?

By default, both paths are located in the /mirotalksfu/app/rec or /app/rtmp folders. On Cloudron, they appear to be located at /app/code/app/rec or /app/code/app/rtmp as per your previous messages?

[MiroTalk]

@shrey said in MiroTalk SFU: Recording not possible?:

{
Nov 13 19:11:04 errno: -2,
Nov 13 19:11:04 code: 'ENOENT',
Nov 13 19:11:04 syscall: 'mkdir',
Nov 13 19:11:04 path: '/app/code/app/rec/'
Nov 13 19:11:04 }

I think the main issue is a missing volume mount:

• The container is trying to create /app/code/app/rec/, but this path doesn’t exist inside the container and isn’t mapped to any mounted volume.
• Since Docker containers are isolated, any folder that isn’t part of a volume or explicitly created inside the container won’t persist and may fail to be created due to permissions.

Something like:

volumes:
  - /mirotalksfu-path-on-cloudron/app/rec:/app/code/app/rec
  - /mirotalksfu-path-on-cloudron/app/rtmp:/app/code/app/rtmp

This way, both /rec and /rtmp directories are properly mounted and writable.

[MiroTalk]

Ok from what understand: Cloudron allows writing only to /app/data, while /app/code is read-only, so all dynamic folders (rec, rtmp, uploads, etc.) must be moved into /app/data.

[nebulon]

Thanks for all the insights here. So I think the folder to store recordings should then default to /app/data/rec or so with an option to configure that to use a different volume (not sure how large those recordings are)

For RTMP_DIR is this some kind of temporary directory and thus maybe should be configured as /tmp/... or maybe even /run/... ?

[MiroTalk]

Yeah, setting the recordings directory RECORDING_DIR to /app/data/rec makes sense. This keeps all generated recordings inside the application’s persistent data area, which is consistent and easy to manage.

Regarding RTMP_DIR, it is not a temporary directory.
This directory is used to store the media files that will be streamed via RTMP. Since these files may need to remain available for repeated or scheduled streaming, it’s better to keep them in a persistent and organized location. Can be also in /app/data/rtmp as consistent with the rest of the project’s data layout.

So in summary:

• RECORDING_DIR → /app/data/rec
  Stores recordings generated by the application.

• RTMP_DIR → /app/data/rtmp
  Stores video files intended for RTMP streaming, not temporary, should persist.

[nebulon]

perfect, I will prepare a package update then. So just to double check, this only applies to the SFU flavor of mirotalk?

[MiroTalk]

perfect, I will prepare a package update then. So just to double check, this only applies to the SFU flavor of mirotalk?

WIP on MiroTalk SFU: Let me fix this first, then I’ll ping you when done

[nebulon]

in case your code would ensure the paths via "mkdirp()" it would make the package code easier

[MiroTalk]

@nebulon @James @shrey

Implemented in MiroTalk SFU v2.0.14 — Docker image is building now (available in ~1 hour).

• Commit
• Build

For Cloudron deployments, server-side recording should now work using the following configuration:

Recording

RECORDING_ENABLED=true
RECORDING_DIR='../data/rec'            # Path relative to /app/code → resolves to /app/data/rec
RECORDING_MAX_FILE_SIZE=1073741824     # Max file size in bytes (default: 1GB)

RTMP

RTMP_DIR='../data/rtmp'                # Path relative to /app/code → resolves to /app/data/rtmp

Note

If the target directories do not exist, MiroTalk SFU will automatically create them at runtime, just like before.

Cloudron automatically mounts /app/data, so using ../data/... ensures the app writes to the persistent, writable directory.

[nebulon]

New package is out. Thanks for all the work @mirotalk-57bab571 and being so proactive here!

[MiroTalk]

@nebulon said in MiroTalk SFU: Recording not possible?:

New package is out. Thanks for all the work @mirotalk-57bab571 and being so proactive here!

Good! I’m always here to help. Thanks to Cloudron for trusting MiroTalk and supporting us! By the way, I love the new Cloudron UI v.9.0.10, it looks amazing!

[MiroTalk]

PS: Thanks also to @James for his IT support and excellent debugging and suggestions.

[shrey]

Hi @nebulon @mirotalk-57bab571
So, i'm still unable to boot up the app after setting RECORDING_ENABLED=true :

Nov 15 09:36:54 node:fs:1364
Nov 15 09:36:54 const result = binding.mkdir(
Nov 15 09:36:54 ^
Nov 15 09:36:54 2025-11-15T04:06:54Z
Nov 15 09:36:54 Error: ENOENT: no such file or directory, mkdir '/app/code/app/rec/'
Nov 15 09:36:54 at Object.mkdirSync (node:fs:1364:26)
Nov 15 09:36:54 at Object.<anonymous> (/app/code/app/src/Server.js:280:12)
Nov 15 09:36:54 at Module._compile (node:internal/modules/cjs/loader:1554:14)
Nov 15 09:36:54 at Object..js (node:internal/modules/cjs/loader:1706:10)
Nov 15 09:36:54 at Module.load (node:internal/modules/cjs/loader:1289:32)
Nov 15 09:36:54 at Function._load (node:internal/modules/cjs/loader:1108:12)
Nov 15 09:36:54 at TracingChannel.traceSync (node:diagnostics_channel:322:14)
Nov 15 09:36:54 at wrapModuleLoad (node:internal/modules/cjs/loader:220:24)
Nov 15 09:36:54 at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:170:5)
Nov 15 09:36:54 at node:internal/main/run_main_module:36:49 {
Nov 15 09:36:54 errno: -2,
Nov 15 09:36:54 code: 'ENOENT',
Nov 15 09:36:54 syscall: 'mkdir',
Nov 15 09:36:54 path: '/app/code/app/rec/'
Nov 15 09:36:54 }
Nov 15 09:36:54 2025-11-15T04:06:54Z
Nov 15 09:36:54 Node.js v22.14.0
Nov 15 09:36:54 \

[MiroTalk]

@shrey said in MiroTalk SFU: Recording not possible?:

So, i'm still unable to boot up the app after setting RECORDING_ENABLED=true

Forget the previous env configuration. In the latest Cloudron commit, recording is enabled by default, and the app/data path now appears to be automatically resolved as well.

[shrey]

@mirotalk-57bab571

I restarted the updated app, but i still get only this:

No rec folder available, and no default recording taking place.

[shrey]

@mirotalk-57bab571

It seems like 2 separate updated packages have been released for this.
Just came across the 2nd one and updated the app again.

1. The rec folder is now available in /app/data/
2. All recordings are still being saved on the local device only. No server-side recording. No S3 recording.

[james]

Hello @shrey
I have just updated my Mirotalk SFU app and now the recordings are stored inside the Mirotalk SFU app in /app/data/rec/.
Please share your /app/data/env file.
With the updated app and a fresh installed app the recording works.
In a meeting I can do:

ls -lah /app/data/rec/
total 5.2M
drwxr-xr-x 2 cloudron cloudron 4.0K Nov 15 09:46 .
drwxr-xr-x 3 cloudron cloudron 4.0K Nov 15 09:44 ..
-rw-r--r-- 1 cloudron cloudron 5.2M Nov 15 09:46 Rec_09598YoungSpid_2025_11_15_10_45_32_e0005370-10dd-4487-a68e-cff4d94f274d.webm

[shrey]

Hi @james , thanks for the screenshots. I can now see that there's a "Save on server" option in the UI, and it's working for me as well.

Now, just S3 is left to work.
My env file ->

# Recording
RECORDING_ENABLED=true                           # Enable recording functionality (true|false)
RECORDING_UPLOAD_TO_S3=false                      # Upload recording to AWS S3 bucket [true/false]

# AWS S3 Configuration  
AWS_S3_ENABLED=true                              # Enable AWS S3 storage (true|false)  
AWS_S3_BUCKET_NAME=<bucket-name>                       # Name of your S3 bucket (must exist)  
AWS_ACCESS_KEY_ID=<key-id>                                # AWS Access Key ID (leave empty for IAM roles)  
AWS_SECRET_ACCESS_KEY=<key-secret>                            # AWS Secret Access Key (leave empty for IAM roles)  
AWS_REGION=<region>                                   # AWS region (e.g., us-east-2, eu-west-2)  
AWS_S3_ENDPOINT=https://<region>.digitaloceanspaces.com

Note: Although i didn't find the "AWS_S3_ENDPOINT" key in the env template, i configured it because it seems to work with most S3 client libraries, and is a necessity to be able to connect to S3 spaces other than AWS.

[james]

Hello @shrey
The library used in MiroTalk SFU for AWS/S3 is aws-sdk/client-s3.
It seems MiroTalk SFU does not have the option to configure the endpoint.
From the MiroTalk SFU Code handling the configuration:

https://github.com/miroslavpejic85/mirotalksfu/blob/b2a41e597610524b259097d2e1b52674dda631c0/app/src/config.template.js#L948-L954

        aws: {
            enabled: process.env.AWS_S3_ENABLED === 'true',
            accessKeyId: process.env.AWS_ACCESS_KEY_ID || 'your-access-key-id',
            secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY || 'your-secret-access-key',
            region: process.env.AWS_REGION || 'us-east-2',
            bucket: process.env.AWS_S3_BUCKET || 'mirotalk',
        },

Also in the server.js where the S3Client is initialized, the endpoint is never configured, thus using the default, resolving the endpoint from the AWS_REGION.
https://github.com/miroslavpejic85/mirotalksfu/blob/b2a41e597610524b259097d2e1b52674dda631c0/app/src/Server.js#L297-L303

const s3Client = new S3Client({
    region: config?.integrations?.aws?.region, // Set your AWS region
    credentials: {
        accessKeyId: config?.integrations?.aws?.accessKeyId,
        secretAccessKey: config?.integrations?.aws?.secretAccessKey,
    },
});

So we need to ask @mirotalk-57bab571 to add the option to configure the endpoint as well.
Adding to that, when a non AWS endpoint is used, the option forcePathStyle: true might also be needed for the best compatibility with e.g. MinIO and most S3-compatible systems.

---

@mirotalk-57bab571
It is the weekend, please don't feel pressured or forced to work on the weekend.
Would it be possible to add the option to configure the S3Client endpoint config and S3Client forcePathStyle config?