Opening a file should feel straightforward. Behind that click, a storage application has to establish who you are, check which bucket you can access, retrieve the right object and handle failures without exposing credentials.
This is a look at the AWS resources behind app.bucketdesk.com as of September 2026. It describes the application deployment, not the separate marketing website. The aim is not to use as many managed services as possible. It is to give each part of the system a clear job and make the tradeoffs visible.
Follow a request from browser to bucket
A browser request arrives at an Application Load Balancer over HTTPS, using a certificate from AWS Certificate Manager. The load balancer forwards it to the Laravel application running on Amazon ECS Fargate.
Laravel checks the signed-in user, organization membership, connection and permitted storage scope. For an authorized storage request, the application uses AWS STS to assume a role in the customer account. That temporary session accesses the approved S3 bucket and prefix. The application then returns the listing or prepares the supported preview.
The original objects remain in the connected bucket. This does not mean file bytes never pass through BucketDesk: preview delivery can involve the application. Source ownership and the path used to deliver a preview are different questions.
Two application services, not a fleet of microservices
ECS runs separate web and worker services on Fargate. The web service handles interactive requests. The worker provides a separate execution path for queued work, so a background job does not need to run inside the browser request that initiated it.
Fargate removes the need to maintain EC2 hosts for these containers. It does not remove capacity planning: CPU, memory, task count and queue behavior still matter. Web autoscaling is configured around CPU utilization, while the worker has its own task allocation.
Separating the services is a useful starting boundary, not proof that every future processing feature is available or fully isolated. Archive processing, agents and other workflows still need their own implementation and resource controls.
PostgreSQL keeps application records; Redis keeps work moving
Amazon RDS for PostgreSQL stores application records such as users, organizations, connections and audit history. It is not a full-text index of every file in a customer bucket.
Amazon ElastiCache Redis supports Laravel sessions, queues and application caching. A session, a queued job and a cached application value are different from a cached copy of an S3 file. Using Redis does not mean BucketDesk automatically mirrors customer buckets or eliminates retrieval charges.
The current database uses a single Availability Zone, and Redis has one node. Those choices keep the baseline smaller, but they are not a highly available data tier. Redundancy, recovery objectives and capacity should evolve with measured demand and the service commitments we make.
Prefix search does not need an index
The dashboard searches using the S3 ListObjectsV2 API. If you are browsing Finance/2026/ and enter inv, the application requests keys beginning with Finance/2026/inv. Results are paginated, and matching subfolders remain navigable.
This is case-sensitive prefix matching, not substring or document-content search. Typing invoice at the bucket root will not find Finance/2026/invoice.pdf. That limitation is deliberate: the interface uses the bucket namespace directly rather than maintaining a separate catalog.
Search runs when you submit it, not on every keystroke. There is no indexing job to fund or synchronize. S3 listing requests still have a cost; removing an index does not make storage access free.
Customer access has two permission boundaries
BucketDesk uses IAM roles and temporary STS credentials for customer bucket access rather than collecting long-lived customer access keys. The customer role determines which AWS operations are allowed. The application separately checks whether the current user may use that connection and scope.
Both checks matter. A valid login does not grant access to every connected bucket, and an IAM role does not replace organization-level authorization. Temporary credentials expire, but expiration alone is not a substitute for narrow permissions.
Secrets Manager holds deployment secrets, including application, database and Redis secrets. VPC subnets and security groups separate the network paths for the load balancer, application and data services. These are concrete controls, not a claim of certification or complete protection.
Logs should explain failures, not collect documents
CloudWatch receives application logs and service metrics. The deployment includes an alarm for web server errors, while load balancer access logs are stored in S3. Application audit events provide another view of user actions.
These signals answer different questions. A request failure, a queue delay and an authorization denial should not be treated as the same incident. Logs and metrics are also not equivalent to complete distributed tracing; this architecture inventory does not claim that an end-to-end trace exists for every request.
Credentials, signed URLs and document contents do not belong in ordinary diagnostic logs. For prefix search, the audit metadata records that a prefix search occurred and the result count rather than adding the search text to the event.
Email and deployment have their own infrastructure
Amazon SES is the configured transport for account email. A verified sender domain and successful DKIM setup are only part of that setup. Sending to arbitrary signup addresses also requires SES production access; application configuration alone does not establish delivery readiness.
ECR stores container images, and CDK with CloudFormation manages infrastructure updates. A release replaces application tasks through a rolling deployment and is checked against the expected build and application readiness. A small Lambda deployment helper publishes onboarding templates to S3; it is not the server handling file previews.
This makes supporting resources easier to understand: the template bucket helps customers establish access, the log bucket stores operational records, and customer buckets hold the source files. They serve separate purposes.
A smaller baseline still has a real bill
The recurring baseline includes the running Fargate tasks, load balancer, database and Redis node. Storage, requests, logs, public IP addresses, email and data transfer can add usage charges. The final bill depends on traffic and configuration, so this article does not present an unmeasured monthly estimate.
Customer S3 operations can also generate charges in the customer account. That does not mean every part of the product is customer-funded: BucketDesk still operates its application infrastructure. Any future customer-funded processing model needs to be implemented before it is described as current behavior.
The useful optimization is to avoid work the user did not request. Prefix search needs no index. A file should not be downloaded merely because somebody typed a character. A background service should earn its place by supporting a real workflow.
Keep the workspace responsive, keep access scoped, and make the cost and reliability boundaries explicit. More AWS services do not automatically make a better file experience; clear responsibilities do.