Deploying to gh-pages from @ litestar-org/advanced-alchemy@a6e275d 🚀

Author: cofin

732/_sources/usage/frameworks/fastapi.rst.txt

@@ -315,10 +315,5 @@ In production, keep object storage credentials out of application code. Point ``
 the real bucket or prefix you use in production and let the runtime provide credentials through the
 platform's normal mechanism, such as an IAM role, IRSA, ECS task role, or other ambient credentials.
 
-For local S3-compatible development, use RustFS with an app-owned bucket. The runnable
-``examples/fastapi/fastapi_fileobject.py`` example points at ``http://localhost:9000`` with
-RustFS's default ``rustfsadmin`` credentials and expects the ``static-files`` bucket to exist before
-the application starts.
-
 The storage backend key must match in both places: the ``StoredObject(backend="...")`` column
 definition and the ``FileObject(backend="...")`` values you create from incoming uploads.

732/_sources/usage/frameworks/litestar.rst.txt

@@ -1073,11 +1073,6 @@ For production deployments, avoid development-only endpoints and hardcoded objec
 in application code. Configure the backend with the real bucket or prefix and rely on the platform's
 ambient credentials, such as IAM roles or workload identity.
 
-For local S3-compatible development, use RustFS with an app-owned bucket. The runnable
-``examples/litestar/litestar_fileobject.py`` example points at ``http://localhost:9000`` with
-RustFS's default ``rustfsadmin`` credentials and expects the ``static-files`` bucket to exist before
-the application starts.
-
 **Supported Storage Backends**:
 
 - **Local filesystem**: For development and simple deployments

732/_sources/usage/modeling/types.rst.txt

@@ -222,10 +222,6 @@ Storage Backends
 - **FSSpec Backend**: Supports various storage systems using the ``fsspec`` library.
 - **Obstore Backend**: Provides a simple interface for object storage (S3, GCS, etc).
 
-For local S3-compatible testing, use RustFS with a bucket owned by the application or test. Pytest
-integration tests can use ``pytest_databases.docker.rustfs`` and its ``rustfs_default_bucket_name``
-fixture; standalone examples should create their own bucket, such as ``static-files``.
-
 Metadata
 ~~~~~~~~
 

732/searchindex.js

@@ -641,10 +641,6 @@ <h2>File Object Storage<a class="headerlink" href="#file-object-storage" title="
 <p>In production, keep object storage credentials out of application code. Point <code class="docutils literal notranslate"><span class="pre">ObstoreBackend</span></code> at
 the real bucket or prefix you use in production and let the runtime provide credentials through the
 platform’s normal mechanism, such as an IAM role, IRSA, ECS task role, or other ambient credentials.</p>
-<p>For local S3-compatible development, use RustFS with an app-owned bucket. The runnable
-<code class="docutils literal notranslate"><span class="pre">examples/fastapi/fastapi_fileobject.py</span></code> example points at <code class="docutils literal notranslate"><span class="pre">http://localhost:9000</span></code> with
-RustFS’s default <code class="docutils literal notranslate"><span class="pre">rustfsadmin</span></code> credentials and expects the <code class="docutils literal notranslate"><span class="pre">static-files</span></code> bucket to exist before
-the application starts.</p>
 <p>The storage backend key must match in both places: the <code class="docutils literal notranslate"><span class="pre">StoredObject(backend=&quot;...&quot;)</span></code> column
 definition and the <code class="docutils literal notranslate"><span class="pre">FileObject(backend=&quot;...&quot;)</span></code> values you create from incoming uploads.</p>
 </section>

732/usage/frameworks/fastapi.html

@@ -1568,10 +1568,6 @@ <h2>File Object Storage<a class="headerlink" href="#file-object-storage" title="
 <p>For production deployments, avoid development-only endpoints and hardcoded object-store credentials
 in application code. Configure the backend with the real bucket or prefix and rely on the platform’s
 ambient credentials, such as IAM roles or workload identity.</p>
-<p>For local S3-compatible development, use RustFS with an app-owned bucket. The runnable
-<code class="docutils literal notranslate"><span class="pre">examples/litestar/litestar_fileobject.py</span></code> example points at <code class="docutils literal notranslate"><span class="pre">http://localhost:9000</span></code> with
-RustFS’s default <code class="docutils literal notranslate"><span class="pre">rustfsadmin</span></code> credentials and expects the <code class="docutils literal notranslate"><span class="pre">static-files</span></code> bucket to exist before
-the application starts.</p>
 <p><strong>Supported Storage Backends</strong>:</p>
 <ul class="simple">
 <li><p><strong>Local filesystem</strong>: For development and simple deployments</p></li>

732/usage/frameworks/litestar.html

@@ -599,9 +599,6 @@ <h3>Storage Backends<a class="headerlink" href="#storage-backends" title="Link t
 <li><p><strong>FSSpec Backend</strong>: Supports various storage systems using the <code class="docutils literal notranslate"><span class="pre">fsspec</span></code> library.</p></li>
 <li><p><strong>Obstore Backend</strong>: Provides a simple interface for object storage (S3, GCS, etc).</p></li>
 </ul>
-<p>For local S3-compatible testing, use RustFS with a bucket owned by the application or test. Pytest
-integration tests can use <code class="docutils literal notranslate"><span class="pre">pytest_databases.docker.rustfs</span></code> and its <code class="docutils literal notranslate"><span class="pre">rustfs_default_bucket_name</span></code>
-fixture; standalone examples should create their own bucket, such as <code class="docutils literal notranslate"><span class="pre">static-files</span></code>.</p>
 </section>
 <section id="metadata">
 <h3>Metadata<a class="headerlink" href="#metadata" title="Link to this heading">¶</a></h3>