How Loki uses Ceph RGW as its S3 backend
Loki writes its compressed log chunks and its TSDB index to an S3 API endpoint, and Ceph RGW can provide that endpoint. In Loki's storage configuration, the index is set with store: tsdb and the object store with object_store: s3, and the S3 client is pointed at the RGW endpoint with s3forcepathstyle: true so that bucket names are carried in the request path rather than in the hostname. Loki can use any service that implements the S3 API, but its documentation lists S3-compatible stores such as MinIO as supported without typically recommending them for production, and it recommends Amazon S3, Google Cloud Storage and Azure Blob Storage for production use. A Ceph RGW deployment is therefore a supported configuration on paper, not a pre-validated one. Treat it as something your team must test and size itself before any log data depends on it.
The practical work sits in three places. First, confirm with your RGW deployment that path-style addressing works end to end, including the endpoint scheme, certificate trust on every Loki component that writes or reads, and the access key and secret key that Loki uses. Second, decide how many buckets Loki will use and how they map to the chunk and index data, and confirm the layout with a short ingest and query test before loading production volumes. Third, plan for the write and read load that compaction and queries place on RGW, because the compactor and queriers issue many small and listing requests. Ask your Ceph team to benchmark the gateway with a representative object size and request mix, and check the Loki release you plan to run against the current Grafana Loki storage documentation before you fix the configuration.
Retention is the setting most likely to be forgotten. Loki's compactor applies retention, and it is disabled by default, so logs accumulate in RGW indefinitely until retention_enabled is set. Decide retention per tenant or per stream selector before go-live, remember that each stream rule must be at least 24 hours, and confirm with your storage team how much capacity the chosen retention needs on the Ceph pools behind the bucket, including replication or erasure coding overhead. Also confirm which Loki release you will run, because the Loki release notes and deployment documentation change over time and the supported deployment modes affect how many components write to the object store.
What you need before configuring Loki on RGW
Loki on Ceph RGW depends on five decisions made before any configuration file is edited: the Ceph release, the RGW endpoint, the S3 identity, the Loki release and the tenancy model. Each card below names one of these and what to confirm, so the storage and Loki settings that follow have a stable base.
Confirm the Ceph release
Tentacle (20.2.x) and Squid (19.2.x) are the actively maintained Ceph releases on the Ceph releases page, and both receive periodic backports and security fixes. Confirm which of the two your cluster runs and its current point release before you test S3 calls from Loki. Plan your upgrade path against the Ceph end-of-life dates, because a cluster that falls out of maintenance will receive no further fixes for its RGW code.
Reachable RGW endpoint
Loki hosts must reach the RGW endpoint over the network path your ingesters, queriers, compactor and index gateway use. Confirm that the endpoint resolves from every Loki node, that the load balancer or ingress in front of RGW passes S3 traffic without rewriting it, and that DNS names match the certificate. Ask who owns the RGW service and whether it is deployed with cephadm, which manages RGW as containerized services.
S3 user scoped to Loki buckets
Create a dedicated RGW user for Loki with an access key pair that can read and write only the chunk and index buckets Loki uses. Do not reuse an administrator or a general application identity, because Loki's compactor also deletes objects when retention is enabled. Record the key ownership and rotation process in the same change, so that revoking one Loki credential does not disturb other services on the cluster.
Loki release to deploy
The Loki GitHub releases page lists v3.7.8 as the latest release, published September 17, 2026. Pin the exact version in your deployment manifests and read its release notes before you change storage settings, since storage and schema behavior can change between minor releases. Check the release notes for any deprecation that affects your deployment mode, because Loki documents simple scalable mode as deprecated and scheduled for removal with Loki 4.0.
TLS certificates for the RGW endpoint
Decide whether Loki connects to RGW over HTTPS, and if so, which certificate authority signs the endpoint certificate. Loki's S3 client must trust that CA, so the internal root or intermediate must be installed in the Loki container image or mounted into it. Confirm the certificate subject alternative names include the exact hostname in the endpoint setting, and plan renewal, because an expired certificate stops ingest and queries at once.
Tenancy and the reverse proxy
Decide early whether Loki runs single-tenant or multi-tenant. Multi-tenancy requires auth_enabled set to true, and every request must carry an X-Scope-OrgID header that identifies the tenant. Loki has no built-in authentication layer, so the documentation requires an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Decide the tenant names and the proxy design now, because changing tenancy later changes how data is stored and queried.
Configuration sequence for Loki on Ceph RGW
This sequence takes a Loki instance from an empty Ceph RGW to a working TSDB and S3 setup, with each step closed by a check that confirms the data path before the next step begins. It is meant for the platform engineer who will run Loki and the Ceph administrator who will provision the storage.
Create the RGW user and log buckets
The Ceph administrator creates a dedicated RGW user for Loki and one or more buckets for chunks and index files, using the naming and ownership your storage team already applies to other S3 workloads. Keep the Loki user separate from administrative and backup users so its access key can be rotated and scoped on its own. Confirm the outcome by listing the buckets as the Loki user with an S3 client and checking that the buckets exist, are owned by that user, and are empty before Loki writes to them.
Set the storage_config s3 block
The platform engineer adds an s3 block under storage_config in the Loki configuration, pointing the endpoint at the RGW address, supplying the Loki user's access key and secret, and setting the bucket name and region values your RGW deployment expects. Set s3forcepathstyle to true, since Loki's documented example for S3-compatible stores uses path-style access and RGW buckets are addressed that way in this setup. Keep the secret out of the configuration file where your secret store allows it, and confirm the endpoint uses HTTPS if your RGW serves TLS. The check is a Loki startup log with no storage errors, followed by a test list request from the same host using the same credentials.
Point schema_config at tsdb and s3
In schema_config, the platform engineer sets the index store to tsdb and the object store to s3, with a schema period and a start date that match the first day Loki will receive logs. Using TSDB matters because Loki's documentation recommends it as the index store for version 2.8 and newer, and older index stores are deprecated. Record the chosen start date, since changing schema periods later requires a planned migration. The check is that Loki reports the active schema on startup and the configuration validates without warnings about an unsupported index type.
Configure the compactor and retention
The platform engineer enables the compactor, sets a working directory on local disk, and decides whether retention_enabled should be true at this stage. Loki applies retention through the compactor and leaves logs in place indefinitely until retention_enabled is set, so the value needs to be an explicit decision recorded with the retention periods you agreed with the log owners. Retention can be global, per tenant or per stream selector, and each stream rule must be at least 24 hours. The check is that the compactor starts, logs its retention mode, and shows no errors reading or writing its working files.
Start a single Loki instance
For this first run, the platform engineer starts one Loki process with the configuration from the previous steps, without splitting it into read, write and backend targets. This keeps the first failure in one log stream and makes it clear whether a problem lies in the RGW path or in the scaling layout. Use the single-binary deployment mode for this test and treat it as a validation run rather than the production topology. The check is that Loki reports ready on its health endpoint and the ingester begins accepting writes without authentication or storage errors in its log.
Write test logs and confirm objects in the bucket
The platform engineer sends a small, known set of test log lines to Loki using the push API or an agent such as Grafana Alloy, with a clear label set so the test entries are easy to find. After Loki flushes its chunks, a Ceph administrator or the platform engineer lists the bucket with an S3 client and confirms that chunk objects and TSDB index files appear under the expected prefixes. The check is a bucket listing that shows objects written after the test and no objects written to a different bucket by mistake.
Query the test logs through Grafana
The platform engineer adds Loki to Grafana as a data source, pointing it at the Loki query endpoint, and runs a label-filtered query that matches the test entries written in the previous step. Confirm the returned lines match the sent lines in content and count, which proves the read path works against objects stored on RGW and not only the local cache. If auth_enabled is later set to true, the same test is repeated with the X-Scope-OrgID header. The check is that the query returns the expected lines in Grafana, and that a restart of Loki followed by the same query still returns them, which confirms the data is being read back from the object store.
How bucket layout and retention affect RGW
Loki writes two kinds of data to object storage: compressed log chunks and the TSDB index files that map label sets to those chunks. Both land in the bucket named in the object_store settings, so the bucket layout you choose determines how RGW capacity, permissions and lifecycle behave. Running one bucket per environment or per tenant is a design choice to confirm with your Loki team, not a default the Loki documentation prescribes. Separate buckets make access control and capacity reporting simpler, while a single bucket with tenant prefixes reduces the number of buckets RGW must manage. Decide this before ingest starts, because moving existing chunks between buckets later is manual work.
Retention is applied by the compactor, and it is disabled by default. Until retention_enabled is set, Loki keeps logs indefinitely, so RGW usage grows without any automatic cleanup. Retention can be set globally, per tenant, or per stream selector, and each stream rule must be at least 24 hours. Confirm the retention period for each log source with the owners of those systems, then size the RGW cluster for the peak stored volume at the end of that period, not for the first week of ingest. Ask the team to measure bytes per day per tenant during a representative load test, since compression ratios vary with log content.
Loki's retention works by deleting chunks and index entries itself, so do not add an RGW lifecycle expiration rule on the same prefixes without testing it first. A lifecycle rule that removes objects Loki still indexes can cause query errors that look like storage faults. Check the Ceph Object Gateway lifecycle behavior for your release with your Ceph administrator, and confirm that the compactor's delete path works against your RGW endpoint in a non-production environment. Also plan for the cost of deletes: large retention sweeps generate metadata and data operations on the cluster, so schedule them with the same care you give to recovery and backfill traffic.
Loki settings mapped to RGW and Ceph objects
This table pairs each Loki configuration key in the object storage path with the RGW or Ceph object it needs, so you can trace a setting from the Loki file to the endpoint, user or bucket behind it. Read each row as a checklist: confirm the Loki value matches the RGW value on the same line before the first deployment. The main takeaway is that most failed Loki-to-RGW setups trace back to an endpoint, addressing style or credential mismatch rather than to Loki itself.
| Loki setting | RGW or Ceph counterpart | What to confirm |
|---|---|---|
| storage_config: aws endpoint | RGW endpoint URL, reachable from every Loki component | Use the address of your RGW service or load balancer, and confirm the scheme and port your gateway serves |
| storage_config: aws access key and secret key | Access key and secret key of an RGW user that owns the Loki buckets | Create a dedicated RGW user for Loki and store its keys in your secrets tooling, not in plain config files |
| storage_config: s3forcepathstyle | Path-style addressing against the RGW endpoint | Set to true, as the Loki storage docs show for S3 implementations, and confirm your RGW DNS does not require virtual-host style |
| storage_config: bucket names (chunks and index) | RGW buckets created for Loki chunks and TSDB index | Confirm bucket names are created before Loki starts and that the Loki user has read and write access to each |
| schema_config: store and object_store | store set to tsdb and object_store set to s3 | Loki 2.8 and newer recommend TSDB as the index store, so confirm the schema period and index prefix before go-live |
| compactor: retention_enabled | Lifecycle of objects in Loki buckets, managed by Loki rather than by RGW lifecycle rules | Retention is disabled by default, so set retention_enabled deliberately and test deletion on a non-production bucket first |
| auth_enabled and X-Scope-OrgID | Tenant separation, usually one bucket set per tenant or one RGW user per Loki environment | Confirm whether tenants share buckets or get their own, since auth_enabled true requires X-Scope-OrgID on every request |
| Authenticating reverse proxy in front of Loki | No direct RGW counterpart; RGW credentials stay with Loki components only | Loki has no built-in authentication, so confirm which proxy enforces access and that clients never receive RGW keys |
Sizing RGW for log ingest and queries
In monolithic mode, a single Loki binary handles ingest, indexing, compaction and queries, so all object storage traffic originates from one process. The Loki deployment modes documentation places this mode at up to about 20 GB of logs per day. The request volume is modest, but it is continuous: the write path uploads compressed chunks and TSDB index files, the compactor reads index data and deletes objects when retention runs, and queries read chunks back on demand. Because one process drives all of this, slow RGW responses appear directly as query latency and ingest backpressure.
- Chunk writes: Chunks are uploaded as streams are flushed, so request count follows stream cardinality and flush behavior more than raw byte volume.
- Index writes: TSDB index files are uploaded on a schedule. Confirm the upload and rotation intervals in your configuration before you estimate request rates.
- Compactor reads and deletes: Compaction and retention share the process with ingest, so a large deletion sweep competes with writes on the same RGW gateways.
- Query reads: Wide time ranges fetch many chunks and index files at once, which produces bursts of GET requests.
- Memory: Size the host for peak query and compaction periods, not for quiet hours.
Before co-locating this process with RGW daemons, check how CPU and network are shared on those hosts under peak load.
Simple scalable mode separates the write, read and backend targets, so each group of components sends its own stream of requests to RGW. The Loki documentation places this mode at approaching 1 TB of logs per day. The write target uploads chunks and index files, the read target fetches them for queries, and the backend target runs the compactor, which reads index data and deletes expired objects. Load from the read and write groups can peak at the same time, which makes concurrent request capacity on RGW the number to measure.
- Write target load: Ingest concurrency scales with the number of write replicas, so each added replica adds parallel PUT traffic to the gateways.
- Read target load: Query concurrency scales with read replicas and query size, and it can produce many small GET requests against the same objects.
- Backend target load: Compaction and retention run as bulk reads and deletes, so schedule large sweeps for periods when write and read traffic is lower, and measure their effect.
- Deprecation: The Loki documentation states that simple scalable mode is being deprecated and will be removed with the Loki 4.0 release, so the RGW sizing you do now should be reviewed when you plan a move to another mode.
- Gateway count: Confirm with your Ceph team how many RGW daemons and load balancer endpoints the write and read groups can share without contention.
Record the request rate per target during a test run, because the split between targets is what you will need to revisit when the deployment mode changes.
Microservices mode runs each Loki component as its own deployment, which is the model the Loki documentation recommends for very large clusters. Each component, such as distributors, ingesters, queriers and the compactor, can scale independently, so the total number of clients talking to RGW is the sum of several scaling groups. Request patterns become harder to predict from daily volume alone, because a surge in queries from one team can add GET load while ingest continues unchanged.
- Many concurrent clients: Each scaled component opens its own connections to RGW, so connection limits and gateway threading become sizing inputs.
- Query fan-out: Queriers split a large query into sub-requests, which multiplies the number of reads per user query.
- Load balancing: Spread requests across several RGW endpoints with health checks, and confirm that the balancer does not become the bottleneck.
- Bucket layout: Confirm how bucket index sharding and the number of buckets or prefixes will be set for expected object counts, with your Ceph administrators.
- Failure isolation: Decide whether compaction and query traffic can be throttled or scheduled separately from ingest, so one workload does not starve the others.
Before committing to a microservices layout, ask for a load test that includes concurrent queries alongside a full ingest rate, because that combination is the hardest case for RGW.
The Ceph hardware recommendations advise benchmarking before buying, because no two clusters are alike, and they advise sizing memory for peak use rather than for calm periods. The same reasoning applies to Loki: published mode thresholds describe typical shapes, but your log volume, label cardinality, query patterns and retention settings determine the actual RGW load. A benchmark that replays a representative workload is the most reliable way to test whether the planned hardware and gateway layout hold up.
- Ingest replay: Generate writes at your target daily volume and stream count, and record PUT latency and throughput at the RGW gateways.
- Retention during load: Run a compactor retention sweep while ingest continues, because deletes often reveal contention that steady writes do not.
- Query load: Run concurrent queries across wide time windows and track tail latency, not just averages.
- OSD behavior: Watch OSD commit and apply latency and the placement of WAL and DB devices during the same tests, since object writes land on OSDs.
- Memory at peak: Record gateway and OSD memory during the heaviest combined phase and size from that figure, not from idle readings.
Ask your Ceph integrator to share the benchmark method and raw results before you approve hardware, so you can repeat the test after changes.
Securing the Loki to RGW path
Loki writes compressed chunks and its TSDB index to RGW, and it trusts whatever reaches its query and push endpoints. Securing the path means protecting the S3 connection, giving Loki a narrow RGW identity, encrypting cluster traffic, and placing an authenticating proxy in front of Loki itself. Each control closes a different gap, so review them together before production.
HTTPS to the RGW endpoint
Serve the RGW endpoint over HTTPS with a certificate issued by a CA that Loki's host trusts, and confirm the certificate's subject alternative names match the hostname in the endpoint setting. Plaintext S3 traffic would carry log content and object metadata across the network. Ask your team which CA signs internal certificates and whether Loki's container image needs that CA added to its trust store. Test the connection from the Loki host before enabling it in configuration.
Dedicated RGW user with narrow access
Create a separate RGW user for Loki instead of reusing an administrator or a shared application account. Scope its permissions to the buckets Loki uses for chunks and the index, and deny access to other buckets on the same gateway. Keep the user's name and purpose recorded so access reviews can match it to the Loki deployment. Confirm which bucket policy and user capabilities your Ceph release supports before relying on them.
Encryption inside the cluster
Enable the messenger v2 secure mode so that traffic between Ceph daemons and clients is encrypted after authentication with AES-GCM and carries integrity checks. This protects the path between RGW and the OSDs and monitors, which is separate from the HTTPS connection Loki uses. Confirm the mode is set cluster-wide and that every client you rely on supports it. Check the msgr2 documentation for the exact setting for your release.
Authenticating proxy in front of Loki
Loki has no built-in authentication layer, so anyone who can reach its push or query port can write or read logs. Place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of Loki, and block direct access to Loki's ports from user networks. Set auth_enabled deliberately, because tenant identification through the X-Scope-OrgID header depends on it. Agree with the proxy team which identities may push and which may query each tenant.
Keeping access keys out of config files
Loki's storage configuration includes S3 access keys, and a plain configuration file is readable by anyone with access to the host, its backups or its version control history. Inject the keys at runtime from a secrets store or from environment variables that the orchestrator populates, and restrict file permissions on any rendered configuration. Rotate the RGW key on a schedule and after staff changes, and confirm that the rotation procedure restarts Loki cleanly.
Directory and STS options to confirm
RGW documents LDAP, Keystone and AWS STS authentication options, which could replace long-lived static keys for some deployments. Treat these as possibilities to confirm rather than settled choices, because Loki's S3 client must support the chosen credential flow for your version. Ask your Ceph team which methods are enabled in your cluster, how they handle token lifetime, and whether Loki can use them without manual renewal. Record the decision before go-live.
Common Loki and RGW failures and fixes
Each row pairs a symptom seen in Loki or RGW with its most likely cause and the first check to run. Work through the rows in order, since several symptoms share a root cause such as the endpoint or the credentials.
| Symptom | Likely cause | First check to run |
|---|---|---|
| Loki cannot connect to the S3 endpoint or requests fail to resolve the bucket host | Path-style access is off, so the client sends the bucket name as a subdomain that RGW does not resolve in your network | Confirm s3forcepathstyle is true in the storage_config s3 block and that the endpoint URL includes the correct scheme and port |
| Requests return signature mismatch or access denied errors | Access key or secret key is wrong, belongs to a different RGW user, or the user lacks permissions on the bucket | Test the same key pair with an independent S3 client against the same endpoint and bucket, then compare with the RGW user's keys |
| Loki reports that the bucket does not exist | The bucket was never created, was created in another RGW zone or realm, or the name in the Loki config differs from the bucket name | List buckets as the Loki user and compare the name exactly, including any prefix used in your bucket layout |
| Old logs are not deleted after retention is configured | retention_enabled is unset or false in the compactor configuration, so retention never runs (retention is disabled by default) | Check the compactor block for retention_enabled and retention settings, then confirm the compactor pod or process is running and logging retention activity |
| Compactor logs errors when deleting chunks or index data | The Loki user cannot delete objects, the bucket has versioning or object lock that keeps deleted objects, or the compactor working directory is missing or full | Verify the Loki user can list and delete objects in the bucket, check bucket versioning and lock settings, and confirm the compactor has free local disk |
| Queries are slow or time out under normal load | RGW has too few gateway instances or too little memory, or the OSDs behind the data pool are HDD-backed with no separate metadata media | Watch RGW request latency and error rates during queries, then check OSD latency and whether the index and metadata pools sit on suitable media |
| Ingest backs up or writes fail during peak log volume | RGW gateways are saturated, the load balancer distributes poorly across gateways, or the cluster is short of write capacity during recovery | Compare ingest rate with RGW request rate and cluster health, and confirm the load balancer spreads connections across all gateway instances |
| Tenant data appears mixed or queries return another tenant's logs | auth_enabled is false, so no X-Scope-OrgID header separates tenants, or the proxy in front of Loki strips the header | Confirm auth_enabled in the Loki configuration and send a test request with the expected X-Scope-OrgID header through the full proxy path |
Questions buyers ask before configuring Loki on Ceph RGW
Can our team configure Loki on Ceph RGW without a partner?
Yes, if you already run a Ceph cluster and have engineers who know Loki, S3 and Linux operations. The Loki side is a configuration of the storage block, with store: tsdb, object_store: s3 and s3forcepathstyle: true, as described in the Loki storage documentation. The harder work sits around it: a bucket layout, an access key scoped to those buckets, RGW sized for your write and query load, retention tested end to end, and a reverse proxy in front of Loki because Loki has no built-in authentication. Check whether your team has run RGW in production before committing to the build.
What drives the effort and cost of this setup?
The main drivers are the daily log volume, how long logs must be kept, how many tenants share the platform, the availability design, and how much testing is required. Log volume and retention set the object capacity and the request load on RGW, which in turn decide how many RGW daemons, how much OSD capacity and how much network bandwidth you need. Multi-tenancy and HA add configuration and monitoring work. One-time costs include design, build and verification. Recurring costs include Ceph hardware refresh, capacity growth, patching and Loki upgrades. Ask any quote to list these items separately, and check Loki's deployment modes documentation to confirm which mode matches your volume.
How long does a Loki on Ceph RGW project take?
Duration depends on scope. A single-tenant proof of concept on an existing cluster takes far less time than a multi-tenant production build with a new Ceph cluster, HA proxies, retention policies and a tested restore path. The stages are design, a non-production build, load testing against your expected ingest, a production cutover and handover. Ceph hardware lead times, if you need new servers, often set the critical path more than the Loki configuration does. Ask for a timeline tied to a written scope, with the dependencies you must supply listed separately.
What must our team provide before the work starts?
Expect to provide Ceph administrator access or a named Ceph contact, a clear view of the hardware and network you will use, TLS certificates for the RGW endpoint and the Loki gateway, DNS names, and a list of log sources. Log sources might include Grafana Alloy, Fluent Bit, Fluentd, the Docker logging driver or OpenTelemetry over HTTP, as listed in the Loki send data documentation. You should also decide who owns tenant identifiers, since Loki reads them from the X-Scope-OrgID header when auth is enabled. Identity for the authenticating reverse proxy must be available too.
Does Loki's production caveat for S3-compatible stores apply to Ceph RGW?
Yes, the caveat applies to the decision. Loki's documentation lists Amazon S3, Google Cloud Storage and Azure Blob Storage as recommended production object stores, and says S3-compatible stores such as MinIO are supported but not typically recommended for production. Ceph RGW is not named in that list. Treat it as a supported S3 API target that needs its own evidence: load testing against your ingest and query patterns, failure testing of RGW and OSDs, and a documented restore procedure. Confirm the current wording with Grafana Labs and your own test results, not with this page alone.
Does the AGPLv3 license of Loki affect our plan?
Grafana Labs announced on April 20, 2021 that Loki and its other core projects moved from Apache License 2.0 to AGPLv3, according to the Grafana Labs licensing page. Whether this matters depends on how you use and modify Loki. Internal use without modification generally involves different obligations than offering a modified Loki to outside users over a network, which AGPLv3 addresses. Ceph is licensed under LGPL, which is a separate question. Have your legal or open-source compliance team review the license against your deployment model before the design is final.
What should we check in the Ceph cluster before connecting Loki?
Check that RGW has the capacity and bucket design Loki needs, that the access key is scoped to the Loki buckets only, and that TLS is in place for the endpoint. Confirm the replication or erasure coding choice and the failure domain layout with your Ceph design. Verify that the cluster health is stable under load, since compaction and query traffic can be heavy on the object store. Retention is applied by the compactor and is disabled by default, so set retention_enabled and test deletion on a non-production bucket first, as described in the Loki retention documentation.
What a scoped Loki and RGW engagement covers
A written scope comes before any work starts. DeployOpen first confirms the Ceph release that will serve the buckets, since the actively maintained releases at the time of writing are Tentacle and Squid and each has its own end-of-life date, and the Loki release that will write to them. The scope also records the expected log volume per day, how long each stream must be kept, and whether Loki runs with auth_enabled set to true so that tenants are separated by the X-Scope-OrgID header. Each of these values changes the bucket layout, the RGW capacity and the compactor settings, so none of them is assumed. The client supplies the figures or agrees to a measurement step, and the scope states which deployment mode applies, because simple scalable mode is being deprecated and will be removed with Loki 4.0.
With those inputs fixed, the work covers the Loki side (the object_store: s3 storage block, store: tsdb for the index, s3forcepathstyle for path-style access, and retention rules applied by the compactor), the RGW side (the bucket and user layout, the access keys held by the Loki services, and the RGW capacity sized for ingest and query load), and the authenticating reverse proxy that Loki requires in front of it. DeployOpen builds these in the client's own cloud accounts, data centers or air-gapped network, then tests ingest, query, retention deletion and a restore of a bucket. The deliverables are the configuration, a runbook for operations and a record of test results. The client should confirm who owns the Ceph cluster, which team holds the RGW administrative credentials and who approves production changes before the build begins.
How DeployOpen delivers Loki on Ceph RGW
DeployOpen plans, builds, documents and supports Loki on Ceph RGW inside your own infrastructure. We start from your log volumes, retention rules and tenancy model, then configure the S3 connection, bucket layout and RGW capacity to match, with the engagement agreed in writing before work starts.
How we scope
- Written scope covers Loki deployment mode, expected daily ingest, retention periods and tenant count.
- Scope records the Ceph release, RGW endpoint, bucket names and whether path-style access is required.
- Scope sets which Grafana, Alloy or shipper sources feed Loki and how queries reach users.
How we build
- We configure Loki's TSDB index and object storage client against your RGW endpoint and credentials.
- We set up bucket layout, compactor retention rules and authenticating reverse proxy access for each tenant.
- We test ingest, query and retention behavior on your RGW cluster before the system goes live.
How we hand over
- You receive configuration files, bucket and credential inventory, and a record of RGW sizing decisions.
- Runbooks cover compactor operation, retention changes, RGW capacity checks and recovery steps.
- Handover includes a verification record showing ingest, query and retention tests with their results.
How we support
- Ongoing support, Loki upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover Loki version upgrades, RGW capacity reviews and retention policy changes.
- Confirm the support hours, response terms and upgrade coverage with DeployOpen in the written agreement.
