Build a Local Data Lake with Podman

Run a local S3-compatible data lake with SeaweedFS and Podman volumes.

Introduction

30 Second Summary

Replacing an app should not erase the files it was serving. Reliable storage keeps those files safe while the surrounding software changes.

In this project, you will host a local S3-compatible object store with SeaweedFS 4.47 inside a rootless container managed by Podman. You will prove that a named volume preserves your sensor dataset when the container is replaced.

What You'll Build

You will rebuild your local SeaweedFS service and see the uploaded sensor-readings.csv file remain available through its S3 endpoint.

By the end of this project, you'll have:

  • A local object-storage dashboard where you can open the raw-data bucket and inspect sensor-readings.csv.
  • A working S3 endpoint that returns your CSV rows in Microsoft Edge.
  • A container replacement demo showing that weed-data keeps sensor-readings.csv available after weed-mini is replaced.
  • Secret Mission: Move the persistent SeaweedFS service into a Podman pod named data-lake-pod so it is ready for future companion containers.

Are there any prerequisites?

You need a 64-bit device running Windows 10 Build 19043 or later. Windows 11 also works.

You also need administrator privileges for WSL 2 setup, at least 6 GB of available RAM, internet access, and a little Docker experience.

Before We Start

Before the hands-on setup begins, lock in the local data lake storage layer you are about to build. This checkpoint connects your SeaweedFS object store to the reason its data must live separately from a disposable Podman container.

Set Up Podman on Windows

SeaweedFS runs inside a Linux container. Windows needs WSL 2 plus a Podman machine to provide that Linux environment.

You will prepare WSL 2 first. You will then use Podman Desktop to create the rootless machine that runs your local object store.

In this step, get ready to:
  • Confirm your Windows prerequisites plus Microsoft Edge.
  • Install WSL 2 through an elevated Windows PowerShell session.
  • Install Podman Desktop and create a rootless Podman machine.
Confirm the Windows prerequisites

The container tools depend on a supported 64-bit Windows build. They also need administrator access for WSL setup plus enough memory for the Linux machine.

  • Press the Windows key to open Windows Search.
  • Type winver.exe into Windows Search.
  • Press Enter to open the Windows version dialog.
  • Confirm that your device runs Windows 11 or 64-bit Windows 10 Build 19043 or later.
  • Confirm that your administrator credentials are available for the WSL setup.
  • Confirm that the available memory you checked is at least 6 GB.

Your Windows host meets the baseline when the build requirement passes. The available memory gives the Podman machine enough room to run SeaweedFS later.

  • Press the Windows key to return to Windows Search.
  • Type Microsoft Edge into Windows Search.
  • Press Enter to launch the browser.
  • Confirm that Microsoft Edge loads a new tab without a connection warning.

Microsoft Edge is ready to display the localhost dashboards plus object URLs you create later.

Does the Windows check fall short?

A Windows build below 19043 needs a Windows update before this project can continue.

If the device has less than 6 GB available for the Podman machine, close memory-heavy applications before continuing.

Need help interpreting the version dialog? Help me check whether my Windows device meets the Podman Desktop requirements.

Install and verify WSL 2

WSL 2 supplies the Linux foundation used by the Podman machine. This part needs administrator access because it updates Windows system components.

  • Press the Windows key to open Windows Search.
  • Type Windows PowerShell into Windows Search.
  • Right-click Windows PowerShell in the search results.
  • Select Run as administrator.
  • Select Yes when User Account Control asks for permission.

The title bar shows that Windows PowerShell has administrator privileges. You only need this elevated session for the WSL setup.

  • Update the WSL components by running this command:
wsl --update

What does this command do?

This command updates the WSL components used by the Linux environment. The download can pause while Windows applies the update.

  • Wait for PowerShell to report that the WSL update has completed.
  • Install WSL without adding a separate Linux distribution by running this command:
wsl --install --no-distribution

Why skip a Linux distribution?

Podman Desktop creates and manages its own Linux machine. The WSL platform is the piece this project needs from Windows.

  • Wait for PowerShell to finish enabling WSL.
  • Restart Windows if PowerShell requests a restart.
  • Sign back in after Windows restarts.

WSL setup did not complete?

Confirm that the PowerShell title bar shows administrator access. A standard session cannot complete system-level WSL setup.

Restart Windows when requested before checking the WSL status.

Still blocked? Help me troubleshoot my WSL 2 installation on Windows.

  • Press the Windows key to open Windows Search after the restart.
  • Type Windows PowerShell into Windows Search.
  • Press Enter to open a regular Windows PowerShell session.

Before you check WSL, predict whether Windows will now report an available WSL installation.

  • Check the WSL installation by running this command:
wsl --status

What does this status prove?

The status output confirms that Windows can access WSL after the update plus installation. This gives Podman Desktop a supported Linux provider.

You should see WSL status information instead of a missing-command response. Your Windows host is now ready for the container engine.

Install Podman Desktop and create the machine

Podman Desktop installs the Podman command-line tools. It also manages the Linux machine that runs containers without requiring root privileges.

  • Check whether Podman is already installed by running this command in the Windows PowerShell session:
podman version

What does this check do?

The command reports the installed Podman client plus server versions when the tools are available. Choose the tab that matches your PowerShell result.

✔️ I see the required version

Podman 6.1.2 or later is already available. Continue to the Podman Desktop onboarding instructions below.

  • Keep the current Windows PowerShell session available for the final verification.

ⓧ I see an older version

The installed Podman release is older than 6.1.2. Update Podman Desktop before creating the machine.

  • Return to Microsoft Edge.
  • Visit the official Podman Desktop Windows downloads page.
  • Download the current Windows installer for Podman Desktop 1.29.3.
  • Run the downloaded installer.
  • Complete the installer prompts until Windows confirms the installation.
  • Return to Windows PowerShell.
  • Check the updated Podman version by running:
podman version

What should the updated check show?

The version output should now report Podman 6.1.2 or later. That confirms the command-line tools are current.

Still seeing the older version?

Close every Windows PowerShell window after the installer finishes. A new session reloads the updated command path.

Need help? Help me update Podman on Windows.

ⓧ Command not found

Podman is not installed yet. The official Windows package installs Podman Desktop plus the tools needed for onboarding.

  • Install Podman Desktop from Windows PowerShell by running this command:
winget install RedHat.Podman-Desktop

What does this command install?

Windows Package Manager downloads Podman Desktop from its registered package source. The installation supplies Podman Desktop 1.29.3 plus Podman 6.1.2 for this project.

The installer can take a little while because it downloads the desktop application plus the container engine. Wait for Windows PowerShell to report that the installation completed.

Podman Desktop did not install?

Confirm that the device still has internet access. Windows Package Manager needs to reach its package source.

If the package installation remains blocked, use the official Podman Desktop Windows downloads page to download the Windows installer.

Need help? Help me troubleshoot the Podman Desktop installation.

Podman Desktop onboarding connects the installed tools to WSL 2. It then prepares the controls you need to create a Podman machine.

  • Press the Windows key to open Windows Search.
  • Type Podman Desktop into Windows Search.
  • Press Enter to launch Podman Desktop.
  • Click Next on the Get started with Podman Desktop screen.
  • Click Yes when Podman Desktop asks to begin setup.
  • Confirm that the default WSLv2 virtualization provider is selected.
  • Click Install.
  • Click Close after Podman Desktop confirms the setup.

The Podman tools are now connected to the WSL 2 provider. The remaining job is to give the Linux machine its required memory.

  • Click Settings in Podman Desktop.
  • Select Resources.
  • Click Create new in the Podman tile.
  • Enter podman-machine-default in the Name field.
  • Set Memory to 6 GB.
  • Leave Machine with root privileges disabled.
  • Confirm that Provider Type uses wsl.

Creating the machine can take a little while because Podman is preparing a Linux environment. A quiet progress screen during this stage is expected.

  • Click Create to build the default machine.

Podman Desktop shows the default machine as running when creation finishes. The disabled root-privileges option keeps this machine rootless.

Machine does not start?

Return to the WSL status check above if Podman Desktop cannot create its Linux environment. WSL must be available before the machine can start.

Confirm that the machine has 6 GB of memory plus the wsl provider.

Still stuck? Help me troubleshoot my Podman machine on Windows.

  • Close the current Windows PowerShell window so the installed command path refreshes.
  • Press the Windows key to open Windows Search.
  • Type Windows PowerShell into Windows Search.
  • Press Enter to open a new regular session.

Before you run the final check, predict whether WSL plus the rootless Podman machine will both return status information.

  • Verify WSL plus the running Podman machine by running these commands:
wsl --status
podman version
podman info

What does the final check prove?

  • The first command confirms that WSL is available on the Windows host.
  • The second command reports the Podman client plus server versions.
  • The third command retrieves engine information from the running Podman machine.

You should see WSL status information followed by Podman 6.1.2 version details. You should then see engine information returned by the running machine.

Your Setup Checkpoint

  • Microsoft Edge is available for verifying localhost dashboards plus object URLs.
  • Podman Desktop 1.29.3 is installed with the WSL 2 provider.
  • The default rootless Podman machine has 6 GB of memory. It is running.
  • WSL 2 is installed and available on the Windows host.
  • Windows PowerShell can retrieve information from the running rootless Podman machine.

Your Windows container environment is ready. Next up, you will launch SeaweedFS and open its local administration dashboard.

Launch the SeaweedFS Object Store

Your rootless Podman machine is running. Your Windows PC now has a Linux environment for containers.

An empty container engine gives you little to inspect. A running object store makes the image pull plus runtime configuration visible.

SeaweedFS provides that workload in one container. Its dashboard gives you an immediate visual check of your local S3-compatible object storage.

In this step, get ready to:
  • Launch the pinned SeaweedFS image with four loopback-only published ports.
  • Inspect the container logs in Windows PowerShell.
  • Confirm the running container in Podman Desktop.
  • Verify the dashboard plus local S3 endpoint in Microsoft Edge.
Run the SeaweedFS container

A container image packages the software that Podman starts. Port publishing connects services inside the container to addresses on your Windows host.

The first launch may take a few minutes while Podman downloads the image. That delay is expected.

  • Start weed-mini from the pinned image by running this command in the Windows PowerShell session from earlier:
podman run -d --name weed-mini -p 127.0.0.1:8333:8333 -p 127.0.0.1:8888:8888 -p 127.0.0.1:9333:9333 -p 127.0.0.1:23646:23646 -e S3_BUCKET=raw-data docker.io/chrislusf/seaweedfs:4.47

What Does This Launch Configure?

  • The podman run command creates the container from the SeaweedFS image.
  • The -d flag keeps the container running in the background.
  • The --name weed-mini option assigns a memorable container name.
  • Each -p mapping connects a host port to the matching port inside the container.
  • The explicit 127.0.0.1 address limits every published port to IPv4 loopback.
  • The S3_BUCKET=raw-data setting creates the initial object-storage bucket.
  • The docker.io/chrislusf/seaweedfs:4.47 reference pins the SeaweedFS image version.
  • The command creates a standalone container with no mounted volume.

PowerShell prints a container ID after the service starts. That first container ID is a solid win because your local object store is now running in the background.

Container Failed to Start?

  • Confirm the Podman machine still appears as running in Podman Desktop.
  • Check whether another local program already uses one of the four published ports.

Still blocked? Help me diagnose why my weed-mini container did not start.

Inspect logs and the running container

Container logs reveal what the service writes while it starts. They give you direct evidence that SeaweedFS is running inside weed-mini.

  • Read the latest SeaweedFS startup messages by running this command:
podman logs --tail 20 weed-mini

What Do the Logs Prove?

  • The podman logs command reads output from the process inside the container.
  • The --tail 20 option limits the output to the latest twenty lines.
  • Recent startup messages show that the SeaweedFS process is producing runtime output.

You should see recent SeaweedFS startup messages. Those lines prove the process inside weed-mini is active.

  • Switch back to Podman Desktop from earlier.
  • Locate weed-mini in the container list.
  • Confirm its status shows that the container is running.

You should see weed-mini listed as running. That is a useful checkpoint because PowerShell plus Podman Desktop now agree on the container state.

Logs Missing or Container Not Running?

  • Confirm that weed-mini is spelled exactly the same in PowerShell and Podman Desktop.
  • Verify that the default Podman machine still appears as running.

Need another pair of eyes? Help me find why my SeaweedFS logs or container status are missing.

Verify the dashboard and S3 endpoint

The SeaweedFS Admin UI lets you inspect object-storage buckets. The S3 endpoint is where clients later retrieve stored objects.

Before you check, predict whether the startup logs point to a ready dashboard plus a responding S3 endpoint.

  • Switch back to Microsoft Edge from earlier.
  • Type http://localhost:23646 into the address bar.
  • Press Enter.
  • Select Object Store Management in the dashboard.
  • Confirm that raw-data appears in the bucket list.
  • Open a new Microsoft Edge tab.
  • Type http://localhost:8333 into the address bar.
  • Press Enter.

The SeaweedFS dashboard loads. Object Store Management lists the raw-data bucket.

The S3 endpoint returns a response from SeaweedFS. This proves that the published port reaches the service inside weed-mini.

Why Keep the Service Local?

SeaweedFS is running in Allow All mode because no credentials are configured. This mode keeps the local exercise focused on container behaviour.

The explicit 127.0.0.1 binding limits access to IPv4 loopback on your host. The service stays local to your Windows PC.

You now have a working local object store with a visible bucket. The dashboard plus S3 response confirm that the container and its published ports work together.

Dashboard or Endpoint Not Loading?

  • Confirm that weed-mini still appears as running in Podman Desktop.
  • Check that the dashboard address uses port 23646.
  • Check that the S3 address uses port 8333.

Still unable to connect? Help me troubleshoot my local SeaweedFS dashboard and S3 endpoint.

Your local object store is live. Next, you will add a real CSV dataset to raw-data and retrieve it through the S3 endpoint.

Upload and Read the Sample Dataset

Your local SeaweedFS service is running. Its raw-data bucket is ready to receive an object.

An empty object store only proves that the infrastructure starts. A sample CSV dataset lets you test the whole path from a local file to a browser response through the S3 endpoint.

In this step, get ready to:
  • Create a local sensor dataset with three sample readings.
  • Upload the dataset to the raw-data bucket.
  • Retrieve the uploaded object through its local S3 URL.
Create the sample CSV file

Each row in the dataset records one timestamp, one device ID, and one temperature. Notepad keeps every comma visible while you build the file.

  • Press the Windows key to open Windows search.
  • Type Notepad into the search field.
  • Select Notepad from the search results.
  • Type timestamp,device_id,temperature_c on the first line.
  • Add these readings on the next three lines: 2026-09-25T09:00:00Z,sensor-01,21.4, 2026-09-25T09:05:00Z,sensor-01,21.7, and 2026-09-25T09:10:00Z,sensor-01,22.0.

Your draft now has one header row followed by three sensor readings.

  • Click File in the Notepad menu.
  • Select Save As.
  • Select Documents as the save location.
  • Type sensor-readings.csv in the File name box.
  • Press Enter to complete the save.

You have your source dataset now. The Notepad title bar should show sensor-readings.csv.

File name ends in .txt?

  • Return to Save As in Notepad.
  • Choose the file-type option that keeps all file extensions.
  • Save the file again as sensor-readings.csv in Documents.

Still seeing the extra extension? Help me save this Notepad file with the .csv extension.

Upload the dataset to SeaweedFS

SeaweedFS maps the raw-data bucket to /buckets/raw-data in File Browser. Uploading your local file there turns it into a retrievable object.

  • Switch back to the SeaweedFS dashboard tab in Microsoft Edge from earlier.
  • Select File Browser in the dashboard.
  • Open the buckets folder.
  • Open the raw-data folder.
  • Click Upload in File Browser.
  • Select Documents\sensor-readings.csv in the file picker.
  • Double-click sensor-readings.csv to upload it.

That upload gives your local object store its first dataset. You should see sensor-readings.csv listed inside /buckets/raw-data.

How Does the Bucket Path Work?

The raw-data S3 bucket appears at /buckets/raw-data in File Browser.

Your upload therefore becomes the object raw-data/sensor-readings.csv.

Uploaded File Missing?

  • Check that File Browser is showing /buckets/raw-data.
  • Choose Documents\sensor-readings.csv again if you selected another file.
  • Refresh File Browser if the upload finished without updating the list.

Need a hand? Help me find my uploaded CSV in SeaweedFS File Browser.

Read the object through the S3 endpoint

The local S3 endpoint exposes the uploaded object through a URL. Retrieving that URL proves that the object store can return the same rows you saved locally.

Before you open the object URL, what content do you expect the S3 endpoint to return?

  • Create a new browser tab in Microsoft Edge.
  • Enter http://localhost:8333/raw-data/sensor-readings.csv in the address bar.
  • Press Enter to retrieve the object.

You should see the timestamp,device_id,temperature_c header followed by your three sample rows.

  • Switch back to the sensor-readings.csv file in Notepad.
  • Compare its four lines with the browser response.

You have now traced one dataset from a local file into SeaweedFS and back through the S3 endpoint. The browser response should match the Notepad file exactly.

CSV Not Loading?

  • Check that the address ends with /raw-data/sensor-readings.csv.
  • Switch back to File Browser to confirm that sensor-readings.csv is still listed.
  • Confirm that weed-mini still shows as running in Podman Desktop.

Still unable to retrieve the object? Help me troubleshoot the local SeaweedFS object URL.

Your sample dataset is stored and retrievable through the local S3 endpoint. Next, you will replace the container to test whether that data survives.

Recreate the Container Without Data

Your SeaweedFS object store accepted sensor-readings.csv. The S3 URL proved that the uploaded rows were available.

That copy has never been tested against container replacement. You will replace the current Podman container to discover where those rows actually live.

In this step, get ready to:
  • Remove the current weed-mini container safely.
  • Start a fresh weed-mini container with the same local settings.
  • Test whether sensor-readings.csv survives the replacement.
Remove the current container

Removing a running service can feel risky. Your local Documents\sensor-readings.csv file stays untouched.

The downloaded container image also stays available for the replacement.

  • Switch back to Windows PowerShell from earlier.
  • Remove the current weed-mini container by running these commands in order:
podman stop weed-mini
podman rm weed-mini

What do these commands do?

  • The first command stops the process inside the running container.
  • The second command removes the stopped container instance.
  • Neither command targets your downloaded image or your local CSV file.
  • Switch back to Podman Desktop from earlier.
  • Refresh the container view.

The original weed-mini entry no longer appears. Its downloaded image remains available locally.

Container still listed?

  • Wait a few seconds if the stop operation is still finishing.
  • Run the same two commands again if weed-mini still appears in the container view.

Still stuck? Help me troubleshoot why Podman cannot stop or remove weed-mini.

Recreate the same service

A replacement container can reuse the same image settings. Keeping those settings unchanged makes container replacement the only factor in the survival test.

  • Create a fresh weed-mini container by running this command:
podman run -d --name weed-mini -p 127.0.0.1:8333:8333 -p 127.0.0.1:8888:8888 -p 127.0.0.1:9333:9333 -p 127.0.0.1:23646:23646 -e S3_BUCKET=raw-data docker.io/chrislusf/seaweedfs:4.47

What does this command recreate?

  • The -d flag keeps the replacement container running in the background.
  • The --name weed-mini setting gives the replacement the same familiar name.
  • Each -p mapping uses 127.0.0.1. This keeps port publishing on local loopback.
  • The -e S3_BUCKET=raw-data environment variable creates the raw-data bucket when the fresh service starts.
  • The docker.io/chrislusf/seaweedfs:4.47 image starts the same SeaweedFS release as before.
  • Switch back to Podman Desktop from earlier.
  • Refresh the container view.

The new weed-mini entry shows a running state. This confirms the replacement container started.

Replacement container not running?

  • Confirm the previous weed-mini entry is gone if Podman reports a name conflict.
  • Confirm no other container is using the four published ports if the replacement cannot start.

Need help? Help me troubleshoot why the replacement SeaweedFS container will not run.

Check what survived

Before you check the object URL, do you expect the three uploaded rows to survive the replacement?

  • Switch back to Microsoft Edge from earlier.
  • Enter http://localhost:8333/raw-data/sensor-readings.csv in the address bar.

The browser no longer displays the three CSV rows from the original upload. The object is absent from the fresh service.

Why did the object disappear?

The upload was stored in the original container's writable layer. Removing that container removed the layer that held the object.

The downloaded image only supplies the application files needed to start SeaweedFS. Runtime uploads had remained tied to the removed container.

  • Return to the SeaweedFS dashboard tab from earlier.
  • Refresh http://localhost:23646.
  • Select Object Store Management.

The dashboard loads from the fresh container. You will see raw-data again under Object Store Management.

  • Select File Browser in the dashboard.
  • Navigate to /buckets/raw-data.

The fresh raw-data bucket does not contain sensor-readings.csv. Your local Documents\sensor-readings.csv file remains available.

You have now proved that the service can return while its uploaded object disappears. Next, you will give the dataset storage that survives a fresh weed-mini container.

Persist the Dataset with a Volume

The last container replacement exposed the storage gap in your local data lake. The raw-data bucket returned. The uploaded sensor-readings.csv did not.

A named volume gives Podman storage with a lifecycle separate from the container. Mounting that volume at /data lets SeaweedFS keep the dataset while weed-mini is replaced.

In this step, get ready to:
  • Create a named Podman volume for SeaweedFS data.
  • Launch SeaweedFS with weed-data:/data mounted for persistent storage.
  • Replace the volume-backed container to prove the CSV survives.
Create and inspect the named volume

The current weed-mini still uses its disposable writable layer. Removing it clears the way for a replacement that stores SeaweedFS data in weed-data.

  • Switch back to Windows PowerShell from earlier.
  • Remove the disposable weed-mini container by running these commands:
podman stop weed-mini
podman rm weed-mini

What do these commands do?

  • The first command stops the running container so its process releases the published ports.
  • The second command removes the container and its writable layer.
  • The downloaded SeaweedFS image remains available for the replacement container.
  • Return to Podman Desktop from earlier.
  • Confirm weed-mini no longer appears in the container list.

Container still present?

  • Confirm the container name is exactly weed-mini.
  • Confirm the default Podman machine is still running.

Still stuck? Help me remove the weed-mini container safely.

A named volume remains available after its container is removed. Inspecting it confirms that Podman created the storage independently.

  • Create weed-data and display its details by running these commands:
podman volume create weed-data
podman volume inspect weed-data

What do these commands do?

  • The first command creates the named volume called weed-data.
  • The second command reads the volume metadata from Podman.
  • The volume now exists without depending on any container.
  • Check that the inspection output identifies weed-data as the volume.

PowerShell should show inspection details for weed-data. That output confirms the persistent storage is ready.

Volume details missing?

  • Check that the volume name is spelled weed-data in both commands.
  • Confirm your rootless Podman machine remains running.

Need a hand? Help me troubleshoot the weed-data volume.

Run SeaweedFS on persistent storage

SeaweedFS stores its service data under /data. The weed-data:/data mount redirects that path into the named volume.

  • Launch the volume-backed weed-mini container by running this command:
podman run -d --name weed-mini -p 127.0.0.1:8333:8333 -p 127.0.0.1:8888:8888 -p 127.0.0.1:9333:9333 -p 127.0.0.1:23646:23646 -v weed-data:/data -e S3_BUCKET=raw-data docker.io/chrislusf/seaweedfs:4.47

What does this command do?

  • The weed-data:/data mount connects SeaweedFS storage to the named volume.
  • The S3_BUCKET=raw-data setting creates the object-storage bucket when needed.
  • The 127.0.0.1 bindings keep all four published ports on your Windows device.
  • The container runs SeaweedFS 4.47 in the background under the name weed-mini.
  • Return to Podman Desktop from earlier.
  • Confirm weed-mini appears as a running standalone container.
  • Return to Microsoft Edge from earlier.
  • Open http://localhost:23646 to confirm the SeaweedFS dashboard loads.

The dashboard should load from the replacement container. Its storage now points to weed-data.

  • Select File Browser in the SeaweedFS administration dashboard.
  • Navigate to /buckets/raw-data.
  • Select the upload control.
  • Choose Documents\sensor-readings.csv in the Windows file picker.
  • Confirm the upload.
  • Open http://localhost:8333/raw-data/sensor-readings.csv in Microsoft Edge.

You should see the CSV header followed by your three sample readings. Good progress. Your dataset is now stored through the named volume.

Container or upload missing?

  • Confirm Podman Desktop shows weed-mini as running.
  • Check that the container uses the weed-data:/data mount.
  • Refresh the File Browser after confirming the upload.

Still having trouble? Help me troubleshoot the volume-backed SeaweedFS container.

Replace the container and prove persistence

Container replacement is the durability test. The new container starts with a fresh writable layer while the named volume keeps the SeaweedFS data.

Before you run the replacement, do you expect the CSV to remain available this time?

  • Replace weed-mini with another container using the same volume by running these commands:
podman stop weed-mini
podman rm weed-mini
podman run -d --name weed-mini -p 127.0.0.1:8333:8333 -p 127.0.0.1:8888:8888 -p 127.0.0.1:9333:9333 -p 127.0.0.1:23646:23646 -v weed-data:/data -e S3_BUCKET=raw-data docker.io/chrislusf/seaweedfs:4.47

What happens during replacement?

  • The first command stops the volume-backed container.
  • The second command removes that container and its writable layer.
  • The third command creates a new container with the existing weed-data volume attached at /data.
  • Container removal leaves the named volume in place.
  • Return to Podman Desktop from earlier.
  • Confirm the replacement weed-mini container appears as running.
  • Return to Microsoft Edge from earlier.
  • Open http://localhost:8333/raw-data/sensor-readings.csv.

You should still see the CSV header and all three sample readings. The object survived because its SeaweedFS data remained on weed-data.

  • Compare the displayed rows with Documents\sensor-readings.csv.

The browser rows should match the local file. You have proved that the dataset now persists independently of weed-mini.

CSV missing after replacement?

  • Confirm the replacement command includes weed-data:/data.
  • Confirm the object URL contains the raw-data bucket name.
  • Wait for the SeaweedFS dashboard to load before refreshing the object URL.

Need help recovering the object? Help me diagnose why my CSV did not persist.

Secret mission

Move the Workload into a Pod

Your named volume has separated the data from the container. Move SeaweedFS into data-lake-pod so future companion containers can share its network boundary. Prove the CSV still loads through the pod.

Clean Up Your Resources

Clean Up Your Resources

This project has no cloud charges because every resource uses local disk space or memory on your Windows PC. Choose whether to keep the storage service running, pause it for later, or remove its local resources.

Resources you used:

  • Pod runtime: the data-lake-pod Pod with its weed-mini member container.
  • Persistent storage: the Podman named volume called weed-data. It contains the raw-data bucket plus its persistent CSV object.
  • Local image cache: the SeaweedFS image named docker.io/chrislusf/seaweedfs:4.47 in Podman Desktop.
  • Local sample file: Documents\sensor-readings.csv.

Keep everything running

No action is needed. Choose this option if you want the local dashboard plus S3-compatible endpoint to remain available.

  • Leave data-lake-pod running so the local endpoints stay available.
  • Keep weed-data attached so the raw-data bucket retains its persistent object.
  • Keep Documents\sensor-readings.csv as the source copy of your sample dataset.
  • Refresh http://localhost:8333/raw-data/sensor-readings.csv in Microsoft Edge whenever you want to confirm the storage service is running.

Pause - I'll come back to this later

Pausing releases the Podman machine's active memory while preserving the named volume. Your local endpoints remain offline until you start the machine plus container again.

  • Pause the local storage service by running these commands in the Windows PowerShell session from earlier:
podman stop weed-mini
podman machine stop

What Do These Commands Pause?

  • The first command stops SeaweedFS inside data-lake-pod.
  • The second command powers down the default Podman machine.
  • The weed-data volume remains on disk with the persistent CSV.
  • Return to Podman Desktop to confirm the machine is stopped.
  • Refresh http://localhost:23646 in Microsoft Edge to confirm the dashboard no longer responds.

Your local storage service is now paused. The persistent dataset remains ready for your next session.

Machine Not Stopping?

A running Podman operation can delay the machine shutdown.

Help me pause my Podman machine safely.

Delete - I don't want to use this again

This option removes the project workload plus its stored dataset. The local copy at Documents\sensor-readings.csv stays untouched until the final cleanup.

  • Remove data-lake-pod plus its member container by running this command in the Windows PowerShell session from earlier:
podman pod rm -f data-lake-pod

What Does This Command Remove?

The force flag stops the pod's member container. Podman then removes data-lake-pod.

The weed-data volume remains separate from the deleted pod.

  • Return to Podman Desktop to confirm data-lake-pod no longer appears.
  • Confirm the weed-mini member container no longer appears.
  • Refresh http://localhost:8333/raw-data/sensor-readings.csv in Microsoft Edge to confirm the local endpoint no longer responds.

Pod Removal Not Completing?

A member container may still be shutting down. Give Podman a moment before retrying the same removal command.

Help me remove my Podman pod.

The next deletion is permanent for your uploaded dataset. Your local file remains a separate copy until you remove it below.

  • Delete the unused weed-data volume by running this command:
podman volume rm weed-data

What Does This Command Remove?

Podman removes the unused weed-data volume. This permanently erases the stored raw-data bucket plus its CSV object.

  • Return to Podman Desktop to confirm weed-data is no longer listed.

Volume Still in Use?

Another container may still be mounting the volume. Confirm that data-lake-pod plus weed-mini were removed first.

Help me remove the persistent Podman volume.

Podman Desktop may ask you to confirm removal of the cached image. Removing it frees the local disk space used by that download.

  • Return to Podman Desktop.
  • Locate docker.io/chrislusf/seaweedfs:4.47 in the local image list.
  • Use the image's delete action.
  • Confirm the removal if prompted.
  • Confirm the image no longer appears in Podman Desktop.

Image Still Listed?

A remaining container can keep the image in use. Confirm that no weed-mini container remains in Podman Desktop.

Help me remove the local SeaweedFS image.

The final cleanup permanently deletes the source CSV. Windows asks for confirmation after the keyboard shortcut.

  • Press the Windows key to open Windows search.
  • Type File Explorer.
  • Press Enter to open File Explorer.
  • Select Documents in the left navigation pane.
  • Select sensor-readings.csv.
  • Press Shift+Delete to request permanent deletion.
  • Confirm the permanent deletion when Windows asks.
  • Confirm sensor-readings.csv no longer appears in Documents.

Your project workload plus its stored copies are now removed. That clears the local project data while keeping your reusable Podman tools ready.

Nice Work!

Nice Work!

Project complete! Your local data lake storage layer now runs on Windows with SeaweedFS inside a rootless container managed by Podman.

You've learned how to:

  • Serve a sensor dataset from a local S3-compatible object store through loopback-only published ports. Inspect container logs. Retrieve the stored CSV through its local endpoint in Microsoft Edge.
  • Expose the durability risk of an ephemeral container filesystem by removing weed-mini. Observe that sensor-readings.csv disappears from the recreated service.
  • Protect raw-data/sensor-readings.csv with the named volume weed-data. Replace weed-mini. Retrieve the same object to prove that persistent state remains independent from the container.
  • Secret Mission: Moved the persistent SeaweedFS workload into a Podman pod named data-lake-pod. Kept the persistent CSV available through the pod's shared network boundary.

Ready to quiz yourself?