Managing Laravel Storage Paths and Filesystem Visibility

When Laravel code stores an upload or report, the selected disk and the path passed to it determine where the file goes. A disk is a named storage configuration: it specifies a storage driver, such as local files or Amazon S3, along with a root location and optional settings. Visibility is a public or private setting that Laravel’s filesystem layer translates for the chosen storage driver.

Keep the disk name and the path Laravel returns when it stores a file. Use that same disk and path for later reads, checks, and deletes. A browser URL follows separate rules: the path and visibility setting alone do not create a web address or let visitors reach the file.

How Laravel builds a storage path

Laravel uses the configured default disk when a Storage call omits the disk name. Storage::disk('public'), for example, selects the disk named public. Each disk can point to a different root or remote location, so the same relative path can refer to different files on different disks.

In the Laravel 13 application skeleton, the local disk uses storage/app/private as its root, while the public disk uses storage/app/public. These are skeleton defaults, not requirements for every Laravel project or version. Check the project’s filesystems.php configuration to see which disk and root your code actually uses.

For local storage, Laravel combines the disk root with the path supplied to a storage method. For example:

Storage::disk('local')->put('reports/2026.csv', $contents);

With the Laravel 13 skeleton’s local root, this writes to storage/app/private/reports/2026.csv. Calling the same method on the public disk writes beneath storage/app/public instead. The string reports/2026.csv is relative to the selected disk; it does not choose a disk or make the file public.

A disk can also add a prefix to the path. Laravel’s scoped disks prepend a configured prefix automatically, so pass a path relative to that prefix when you use a scoped disk. If you add the prefix again in the method call, Laravel looks for a different path deeper in the scope. Laravel’s FilesystemAdapter implementation applies the configured root and prefix when it builds paths.

Remote storage follows the same pattern, but the result does not point to a file on the application server. On S3, for example, the relative path identifies an object in the configured bucket. Storage::path() returns a local-style full path for a local disk and a bucket-relative path for S3, so its result is not a browser URL.

Laravel’s makeDirectory method creates a directory and any required parent directories on filesystems that support directories. Object storage such as S3 treats slash-separated names as object paths. A directory-like segment may not correspond to a physical directory.

Store the disk and path used for retrieval

Laravel’s get, exists, and delete methods expect a path relative to the selected disk. If your code writes reports/2026.csv to local, use that path on local later to read, check, or delete the same file. If you pass the same string to another disk, Laravel looks for the file in that disk’s location.

Upload helpers such as putFile can generate a filename and return the stored path. Save that returned path, including the generated filename, rather than trying to reconstruct it later. When code uses multiple disks, save the disk name alongside the path so retrieval uses the same storage location.

Set visibility without confusing it with access

Code can set visibility when it writes a file:

Storage::disk('public')->put('avatars/42.jpg', $contents, 'public');

It can also check or change an existing file’s visibility with getVisibility and setVisibility. For uploads, storePublicly and storePubliclyAs request public visibility explicitly. A disk can define a default visibility as well; Laravel 13’s skeleton configures its public disk with public visibility.

Laravel uses visibility as a label and translates it for the selected storage driver. For local storage, Laravel documents these example permission mappings:

These values are examples for the local driver, not universal access rules. Flysystem explains that each adapter interprets visibility according to its storage system. The label alone does not prove that a file is reachable or protected. Check the storage provider’s permissions and the web server or code rules that control access. For private files, serve downloads through code that checks whether the user is allowed to access the file. A visibility label alone does not check authorization.

Generate URLs from the right disk

A filesystem path identifies a stored file. A URL tells a client where to request it. Use Storage::url() to get the URL configured for the selected disk. Do not use Storage::path() as a web address. Laravel’s file storage documentation describes URL generation for local and S3 disks and notes that a disk’s URL setting can change the base address.

For local files intended for direct web access, Laravel documents storing them on the public disk and linking public/storage to storage/app/public. Run php artisan storage:link to create the symbolic link, a filesystem link from public/storage to storage/app/public. Then use the disk’s URL behavior or a helper such as asset('storage/file.txt'). Setting a file’s visibility to public does not create this link.

The selected disk and its configuration determine how Laravel builds a remote URL. A URL for one disk is not valid for another just because both disks have a file with the same relative path. Laravel also supports temporary URLs for local and S3 storage. These URLs expire, so they serve a different purpose from making a file permanently public. For local storage, temporary URLs can depend on the disk’s serve setting. See Laravel’s temporary URL documentation for the relevant configuration.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com