Skip to main content
No breaking changes are expected, but additional features will be implemented soon.

Overview

Edge Scripting provides support for the Node.js file system API through the node:fs and node:fs/promises modules. This allows you to read, write, and manipulate files and directories within your Edge Scripts. The file system API is based on Deno’s sandboxed environment with Node.js compatibility, supporting both the modern Promise-based API (node:fs/promises) and the traditional callback-based API (node:fs). We recommend using the Promise-based API for cleaner async/await syntax.

Virtual File System

Each script has now access to a Virtual File System that allow to handle file based operations. This file system lives on the Virtual Memory available of the worker. Currently the file directory is composed of two folder:
You can create directories where you want as permissions are not enforced yet. All files are opened in w+.
We suggest you to avoid creating directory in root directory / as we are going to create new folders with differents functions, like /dev/* and other read only directories.
In the Virtual File System, paths are limited to 4096 chars, for instance foo/bar is 7 characters. It’s also limited to 48 segments (a/b/c is 3 segments). Capacity checks for creating, copying and moving are done before the operation. This can result in trying to copy a large file resulting in an out of memory error, even though there is space left to create new files or directories.

Importing the Module

EdgeScripting supports both the modern Promise-based API and the traditional callback-based API.

Callback-based API

Limitations

EdgeScripting’s file system implementation operates in a sandboxed environment with limitations. Understanding these constraints is essential for building reliable applications.
Always handle file system errors gracefully. The sandboxed environment may behave differently from traditional Node.js environments.
Symbolic links and hard links are not supported in the EdgeScripting runtime yet.
The following operations will throw errors or behave unexpectedly:
  • symlink(), symlinkSync() - Creating symbolic links
  • readlink(), readlinkSync() - Reading symbolic links
  • link(), linkSync() - Creating hard links
  • lstat() may not distinguish between files and symlinks correctly
Workaround: Use copyFile() instead of creating links, or restructure your application to avoid link dependencies.

File Statistics - Timestamps

File modification and access times are not reliably available yet.
The following Stats object properties may return incorrect or placeholder values:
  • atime - Last access time
  • mtime - Last modification time
  • ctime - Last status change time
  • atimeMs, mtimeMs, ctimeMs - Millisecond timestamps
  • birthtime, birthtimeMs - File creation time
Reliable Stats properties:
  • size - File size in bytes
  • isFile() - Check if entry is a file
  • isDirectory() - Check if entry is a directory
Example of unreliable usage:

File and Directory Permissions

All files and directories effectively have read/write permissions in the sandboxed environment (644) and are owned by the current (non root) user (uid=1000, gid=1000).
Permission-related operations have limited effect:
  • chmod(), chmodSync() - Not supported
  • chown(), chownSync() - Not supported
  • Stats.mode - Won’t reflect actual permissions
  • Permission checks via access() - Will mostly tell you if a file exists or not.

File Watching

File system watching is not supported.
The following operations are unavailable:
  • watch() - Watch for file changes
  • watchFile() - Poll for file changes
  • unwatchFile() - Stop watching
  • FSWatcher class
Workaround: Use polling with stat() if you need to detect changes, but be mindful of performance implications and CPU time limits.

Performance Considerations

Memory limits: The whole Virtual FileSystem lives inside your script memory. The current file system limits of your script is set up to 64MB. Reading large files may cause memory exhaustion if you store it in memory. Leverage streaming to avoid allocating too much memory at a time.CPU time: File I/O counts toward the 30-second CPU time limit per request.Best practices:
  • Stream large files instead of reading entirely into memory
  • Clean up temporary files to avoid storage bloat
  • See Limits for more details on resource constraints

Quickstart

Here are practical examples showing common file system patterns in EdgeScripting.

Example 1: Reading a File

Example 2: Writing a File

Example 3: Working with Directories

Example 4: Error Handling Patterns

Example 5: Using FileHandle for Chunked Reading

This is not an optimized script at all. This is more to show an example of chunked reading, please avoid using something similar in production.

References