How Loggy Keeps Your Logs Secure with Encryption

If you’re logging anything remotely sensitive - user data, API responses, payment information, error messages that might contain personal details - you’ve probably wondered how safe that data actually is. It’s a fair question, and one we thought about a lot when building Loggy. So let me walk you through exactly how we handle encryption and why we made the choices we did.

Why Encryption Matters for Logs

Here’s the thing about logs: they often contain way more sensitive information than people realize. You might be logging a user’s email address for debugging purposes, or capturing the full request body when something goes wrong, or storing error messages that include database query details. All of that stuff is potentially sensitive, and if your logging provider gets breached or has a rogue employee, that data could be exposed.

Most logging services store your data in plain text, or at best, encrypt it “at rest” with keys they control. That means they can read your logs anytime they want. For a lot of use cases, that’s probably fine - you’re logging things like “user clicked button” or “request took 200ms” and there’s nothing sensitive there. But if you’re in healthcare, finance, or really any industry where data privacy matters, you need something stronger.

How Our Encryption Actually Works

When you enable encryption on your project (available on Pro and Team plans), here’s what happens behind the scenes. I’ll try to explain this without getting too deep into cryptography jargon, but I want you to actually understand what’s going on rather than just trusting us blindly.

When you turn on encryption, we generate what’s called a key pair - a public key and a private key. These two keys are mathematically related in a special way: anything encrypted with the public key can only be decrypted with the private key. The public key gets sent to your application (you’ll add it to your SDK configuration), and the private key stays securely stored on our servers.

Now, when your application sends a log to Loggy… It generates a random encryption key just for that one log entry, encrypts your log message and metadata with that key using AES-256-GCM (which is the same encryption standard used by banks and governments), and then encrypts that random key using your public key. The whole encrypted bundle gets sent to our servers.

Here’s the important part: when you want to view your logs in the dashboard, our server uses the private key we have stored to decrypt the random key, which then decrypts your actual log content. This all happens on our servers, and the decrypted logs are sent to your browser over HTTPS.

Wait, You Store the Private Key?

I know what you might be thinking - “if Loggy stores the private key, can’t they read my logs?” And technically, yes, we could. But here’s why we designed it this way, and why we think it’s actually the right trade-off for most users.

The alternative would be to have you store the private key yourself, either in your browser or somewhere you manage. That sounds more secure on the surface, but it creates some real problems. First, if you lose that key, your logs are gone forever - completely unrecoverable. We’ve seen this happen with other services, and it’s devastating when you need those logs for debugging or compliance and they’re just… gone. Second, it makes the user experience significantly worse. You’d have to manage key backups, handle key rotation, deal with syncing keys across devices and team members. It’s a lot of complexity for most teams to take on.

By storing the private key ourselves, we can ensure your logs are always accessible to you, we can handle key management securely, and the whole experience stays simple. Your logs are still encrypted at rest in our database - if someone broke into our database directly, they’d just see encrypted gibberish. The private key is stored separately as an environment secret, so an attacker would need to compromise multiple systems to actually read your data.

Is this as theoretically secure as true end-to-end encryption where only you hold the keys? No, it’s not. But for the vast majority of use cases, it provides strong protection while keeping things practical and usable. If you’re in a situation where you genuinely can’t trust any third party with your data, you probably shouldn’t be using any cloud logging service at all.

What Gets Encrypted (And What Doesn’t)

When encryption is enabled, we encrypt your log messages and all the metadata you attach to them. So if you’re logging something like loggy.info('Payment processed', { userId: '123', amount: 99.99 }), both the message “Payment processed” and the metadata object get encrypted.

However, we don’t encrypt everything. Timestamps stay unencrypted because we need them to sort and filter your logs by time. Log levels (debug, info, warn, error) stay unencrypted so you can filter by severity. And the project association stays unencrypted so we know which logs belong to which project. None of this metadata is typically sensitive, and keeping it unencrypted means you can still search and filter your logs efficiently.

Setting It Up

Enabling encryption is pretty straightforward. Go to your project settings, flip the encryption toggle on, and we’ll generate your key pair. You’ll get a public key that you need to add to your SDK configuration:

const loggy = CreateLoggy({
  accessToken: 'your-token',
  encryption: {
    enabled: true,
    publicKey: process.env.LOGGY_PUBLIC_KEY
  }
});

From that point on, all new logs from that project will be encrypted. Existing logs won’t be retroactively encrypted - that would require re-processing potentially millions of log entries - but everything going forward will be protected.

If you’re using your own logging library instead of our SDK - maybe you’ve got Winston or Pino set up the way you like it - you can still use encryption. You’ll just need to handle the encryption yourself before sending logs to our API. We provide the public key, and you can use any standard crypto library to do the AES-256-GCM encryption on your end. Check out our developer docs for the exact payload format we expect. It’s a bit more work than using our SDK, but it gives you full control if that’s what you need.

The Bottom Line

Encryption adds a meaningful layer of protection for your log data. It’s not perfect - no security measure ever is - but it significantly raises the bar for anyone trying to access your sensitive information. If you’re logging anything you wouldn’t want exposed in a data breach, it’s worth turning on.

And if you have questions about how any of this works, or if you have specific security requirements we should know about, reach out to us. We’re happy to talk through the details and help you figure out if Loggy’s encryption meets your needs.