DEV Community: TJ-Tronics Systems

Generating AWS S3 presigned URLs in dotnet without dependencies

TJ-Tronics Systems — Thu, 17 Sep 2026 10:28:36 +0000

It is a common requirement to generate AWS S3 presigned URLs for secure, time-limited file uploads to AWS S3 and S3 compatible storage buckets like Cloudflare R2, Backblaze B2, DigitalOcean Spaces or Hetzner Object Storage.

If you look up tutorials to generate a presigned PUT URL for a dotnet application you often find dependencies on the AWSSDK.S3 NuGet package.

A look at their GitHub repo confronts you with a large SDK.

That’s fine if you do multiple, complex things with AWS but if you just want to generate a pre-signed url to allow users to upload files or a profile picture you can solve that with just a few lines of code. Keeping unnecessary dependencies out of your application.

To generate the URL there is no server request required.

Example for Cloudflare R2

In your application secrets store the AccessKeyId and AccessKey to your bucket. The R2 AccountId and R2 Bucket Name are a public part of the upload URL, so you don't need to put them into a secrets store.
You find them when creating a new R2 bucket and adding a Cloudflare Account API Token for access.

The following generates a PUT upload URL with locked in Content Type and File Size:


public class S3Service(AppSettings appSettings)
{

    public string GenerateUrl(string fileName, string contentType, long fileSizeInBytes)
    {
        var now = TimeProvider.System.GetUtcNow();
        string datestamp = now.ToString("yyyyMMdd", CultureInfo.InvariantCulture);
        string amzDate = now.ToString("yyyyMMddTHHmmssZ", CultureInfo.InvariantCulture);

        string host = $"{appSettings.R2UploadsBucketName}.{appSettings.R2UploadsAccountId}.r2.cloudflarestorage.com";
        string credentialScope = $"{datestamp}/auto/s3/aws4_request";

        // query parameters must be alphabetically sorted!
        var queryParams = new[]
        {
            $"X-Amz-Algorithm=AWS4-HMAC-SHA256",
            $"X-Amz-Credential={WebUtility.UrlEncode($"{appSettings.R2UploadsAccessKeyId}/{credentialScope}")}",
            $"X-Amz-Date={amzDate}",
            $"X-Amz-Expires={appSettings.R2UploadsUrlExpiresInSeconds}",
            $"X-Amz-SignedHeaders=content-length%3Bcontent-type%3Bhost"
        };

        string canonicalQueryString = string.Join("&", queryParams);

        // required format: HTTPMethod \n CanonicalURI \n CanonicalQueryString \n CanonicalHeaders \n SignedHeaders \n HashedPayload
        string canonicalRequest =
            "PUT\n" +
            $"/{fileName}\n" +
            $"{canonicalQueryString}\n" +
            $"content-length:{fileSizeInBytes}\n" +
            $"content-type:{contentType}\n" +
            $"host:{host}\n\n" +
            "content-length;content-type;host\n" +
            "UNSIGNED-PAYLOAD";

        string canonicalRequestHash = HashHex(Encoding.UTF8.GetBytes(canonicalRequest));

        string stringToSign =
            "AWS4-HMAC-SHA256\n" +
            $"{amzDate}\n" +
            $"{credentialScope}\n" +
            $"{canonicalRequestHash}";

        byte[] kDate = HmacSha256(Encoding.UTF8.GetBytes("AWS4" + appSettings.R2UploadsAccessKey), datestamp);
        byte[] kRegion = HmacSha256(kDate, "auto");
        byte[] kService = HmacSha256(kRegion, "s3");
        byte[] kSigning = HmacSha256(kService, "aws4_request");

        // calculate signature
        byte[] signatureBytes = HmacSha256(kSigning, stringToSign);
        string signature = Convert.ToHexString(signatureBytes).ToLowerInvariant();

        return $"https://{host}/{fileName}?{canonicalQueryString}&X-Amz-Signature={signature}";
    }

    private static byte[] HmacSha256(byte[] key, string data) => HMACSHA256.HashData(key, Encoding.UTF8.GetBytes(data));
    private static string HashHex(byte[] data) => Convert.ToHexString(SHA256.HashData(data)).ToLowerInvariant();
}

For other upload providers just change the host string to the one defined by your storage provider.

While developing Component4 we aim at keeping unnecessary dependencies out of our system when they’re not there to solve complex use cases (e.g. Stripe.NET for payment processing). They can increase security risks, slow down builds, and can create complex maintenance problems in the long run.

How to deploy a dotnet application without a Dockerfile or Docker build process

TJ-Tronics Systems — Wed, 16 Sep 2026 15:03:58 +0000

When deploying a .net application to a docker container you would commonly use a Dockerfile, build the Docker image then push the Docker image to a registry, pull the whole image from the registry again to the server and run the image.

There are many benefits in doing it that way, especially in larger production environments. But when you’re just testing, deploying to small production or staging environments or just want to run something on a Raspberry PI, there are also drawbacks that can make deployment more time-consuming and complicated than required. These include:

Having to build the whole image, not just your binaries.
Having to write and manage a Dockerfile.
Having Docker installed on the build machine (not every hardware supports or allows virtualization) or setting up a dedicated build pipeline.
Having to pull the base image to the build machine, uploading and then downloading the whole Docker image.
Having to set up a registry where you can upload your image.
Having to rebuild your Docker image when you want to apply an update of the base image (e.g. to close a security vulnerability).
You might not be able to use every image depending on the registry you want to use.
Depending on your environment you might run into limitations. You might have encountered something like “Media type application/vnd.oci.image.layer.v1.tar+zstd not supported”.

When all of that is already in place that’s great. If not, that’s a lot to do if you just want a quick test.

Many tutorials fail to mention that you can just run ready made images executing your compiled binaries directly. There are just 3 steps to run a dotnet application on a Linux Ubuntu server within an Arch Linux Docker container:

Build your application binaries with dotnet publish
Copy your binaries to your Linux server
Set up and run your compose file (or create the container standalone)

1. Build your application

On your machine build your dotnet application to be used with an Arch Linux Base image:

dotnet publish -r linux-musl-x64 -c Release

You do not need a Dockerfile and no docker desktop. No modifications are required within your project. When using .net10 you will find the results in bin\Release\net10.0\linux-musl-x64\publish.

2. Copy your binaries to your server

On your Linux server prepare a directory to upload your binaries. In this example we create bin to hold the binaries. If you want to write out plain log files add a log directory, too. Your directory structure should look something like that:

/opt/stacks
    └── /example-stack
        ├── docker-compose.yml
        └── /app-v1
            ├── /bin
            └── /logs

Copy your binaries from bin\Release\net10.0\linux-musl-x64\publish on your local machine to the bin directory on your Linux server. You can even use Visual Studio Code Remote Explorer to just drag and drop them. Make your binary executable (if you copy a newer version remember to do this again):

sudo chmod +x /opt/stacks/example-stack/app-v1/bin/sample-app

If you want to write out plain log files and you want to use a hardened base image (DHI image) you must adjust access permissions for your log directory:
sudo chown -R 65532:65532 /opt/stacks/example-stack/app-v1/logs
sudo chmod -R 775 /opt/stacks/example-stack/app-v1/logs

3. Set up and run

Add a normal container service to your Docker compose yaml file. Define the image, mount the binary directory, the log directory (optional) and add access to the machine certificates (required if you run an asp.net server and use a DHI image). You may add secrets, networks, dependencies and more.

services:
  app-v1:
    image: dhi.io/aspnetcore:10-alpine
    working_dir: /app
    volumes:
      - ./app-v1/bin:/bin:ro
      - ./app-v1/logs:/app/logs
      - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro
    entrypoint: ["../bin/sample-app"]

Note: If you want to use a docker hardened image from dhi.io do not forget to define your docker.com login credentials. An account is free.
sudo docker login dhi.io -u <your_username>

To run your application, you can now deploy it the usual way:
docker stack deploy --compose-file /opt/stacks/example-stack/docker-compose.yml --with-registry-auth --prune <your_stack_name>

If this is your first time using docker stack remember to init the swarm first. Adjust the advertise-addr if needed.
sudo docker swarm init --advertise-addr 10.20.30.1

To update your application, you can simply copy your new binary (and libraries if they have changed) and update your running service:
docker service update --force <your-stack-name>_app-v1

When deploying a new version to our Component4 staging and testing servers the build process for the binaries takes around 3 seconds, while the whole deploying process is done in less than a minute. It allows us to quickly switch the base image, replace just a single dll or edit appsettings.json directly in place.

Another tip: To use docker secrets with your asp.net application you can use AddKeyPerFile in your Program.cs file:

var builder = WebApplication.CreateBuilder(args);
builder.AddKeyPerFile(directoryPath: "/run/secrets", optional: true);

If you add a load balancer (e.g. traefik) in front of your application you can have multiple versions of your application running at the same time (that’s why we add a v1 to versioned services) and delegate the request based on subdomain, request cookies, query parameters or http headers.

How to manage n8n Workflow status and progress feedback

TJ-Tronics Systems — Mon, 20 Apr 2026 09:32:18 +0000

Workflows in n8n, Zapier or similar tools usually are meant to run in the background. Let's look into how to setup a simple feedback system for n8n workflows to submit status information using DataTabs.

We use a very simple example: A database backup process scheduled to run every day at 3 AM. In this example, we want to be able to see when the workflow was last executed and if the execution was successful.

Managing n8n status feedback with DataTabs

Create a new Document or use an existing one. Open the Layout Editor and add a new DataTab. Give it a label, set the data type to "Text" and enable status. We only want the Api to write, so enable "Api only".

Switch to n8n. In your backup workflow add a new "Http Request" node. Set the method to PATCH, set the URL to https://api.data-tabs.com/v1/documents/doc_... and replace doc_... with your document id. You can copy the id from the url or use the "copy document id" button in the document menu.

Set Authentication to "Generic Credential Type" and select "Bearer Auth" as the Type. If you have already added a DataTabs API Key select it from the list in the Bearer Auth, otherwise select "Create new Credential".

To create a new Api Key open the settings menu in the bottom left corner, select ApiKeys, click "New Api Key". Give it a name to identify it in the list, e.g. "n8n". Click "Create API Key". Copy the key, go to n8n and paste it in the field for Bearer Token. You can edit the name in the top left to something like "DataTabs Api Key" and limit the HTTP Request Domains to "api.data-tabs.com" to prevent mixups. Save your changes.

Enable "Send Body", make sure JSON is selected and switch "Specify Body" to "Using Json". Copy the following request and replace the dt_... with the DataTab id in your document. You can find the id at the end of the editor of your DataTab in the Layout Editor.

{
  "dataTab": "dt_6E55mBFrKaptP7XRtCScdU",
  "value": "Backup completed at {{ $now.toUTC().format('yyyy-MM-dd hh:mm:ss') }} UTC",
  "status": "Ok"
}

Execute the n8n node manually to check if it works. That's it. Your n8 can run locally, no public domain required.

Read more about updating a DataTab value and status in the Documentation.

How to trigger an n8n Workflow from an external Interface

TJ-Tronics Systems — Tue, 14 Apr 2026 14:23:47 +0000

Workflows in n8n, Zapier or similar tools often require to be triggered manually. Either exclusively or as a secondary, manual option.

While it might be acceptable for testing or in private environments to trigger the workflow from the workflow builder, it is often a better approach to separate the building of the workflow from the actual usage. Especially when non-technical users are involved.

The appearance of a workflow builder might discourage non-technical users as they feel overwhelmed with complexity. Often resulting in rejection of otherwise powerful solutions. Acceptance of the workflow solutions can be increased by applying a minimal interface in front of the workflow.

DataTabs presents a convenient, simple to use, safe and mobile friendly alternative to hacks like sending yourself an e-mail or executing a shell script on your local machine.

Creating an n8n workflow trigger with DataTabs

In n8n create a new workflow or use an existing one. Create a workflow trigger “Webhook”. Switch the HTTP method to “POST” and copy the URL. Remember to save or publish the workflow.

Switch to DataTabs and add a new Document. In the Layout editor add a new DataTab and select “Button” as the data type. You can set a name for the button or leave it empty to default as “Run”.

Add POST https://yourdomain.app.n8n.cloud/webhook.... to the Action URL. Replace this URL with the actual one you have copied. The POST prefix is optional. If no prefix is provided, it will default to POST. Now exit the editor. A click on the button will trigger your workflow.

Important note: Your URL must be publicly available. If you use ‘localhost’ or a local IP address, it will not work. For local testing you can add free, temporary domain names via developer tunnels. Some popular options are Cloudflare, Tailscale or ngrok.

Done.