Windows Autostart: Service or Start-On-Login. Comments please!


This is a proper home for the discussion which has started in the threads SyncTrayzor: Windows host for Syncthing. Installer, auto-start, built-in browser, tray icon, folder watcher, and more and Syncthing Windows Installer.

The discussion revolves determining the best approach to starting Syncthing automatically on Windows. The options can be boiled down to “as one service per user”, “as one service for all users”, or “start on login”. A brief summary of my take on the pros and cons is below: I’ll update this as the discussion progresses.

Please leave a comment if you have a preferred approach, if you disagree with anything in this summary, or if you have anything else to add. The ultimate goal is to figure out would could be the best approach - or combination of approaches - to recommend to new Windows users of Syncthing.

One service for all users


  • Syncthing starts before a user logs in, allowing file synchronzation to start earlier.


  • All users (and malware running as those users) will be able to access everything which the Syncthing service’s user can access.
  • This means that running as LocalAdmin creates a vertical privilege escalation attack vector, allowing system files / Program Files to be changed, bypassing UAC.
  • All users have to use the same Syncthing configuration.

One service per user


  • Syncthing starts before a user logs in, allowing file synchronzation to start earlier.
  • User B’s files can sync while user A is logged in.


  • We need to ensure that each Syncthing instance is started on a separate port.
  • Potentially confusing to set up and maintain properly. People are used to seeing one service per program, not one per user. There’s a very large “what the hell” moment if you look at your services list and see “Syncthing (User A)”, “Syncthing (User B)”, etc.

Start on Login


  • Syncthing automatically runs per-user with the user’s permissions - no security holes. This is the way Syncthing is intended to be used (in my understanding), since it stores its config and database in %LOCALAPPDATA%.
  • Different users can use or not use Syncthing as desired.
  • If user A’s Syncthing config causes frequent CPU-intensive scanning, user B won’t be affected.


  • No syncing is done before login.
  • User B’s files aren’t synced while user A is logged in.

@jaredthirsk @Rewt0r @AudriusButkevicius you were involved in previous discussions.


1 Like

As someone new to the project, and with little true technical knowledge, Start on Login has my vote. This would be the behaviour that I would prefer to see, and certainly it would be the behaviour that my family would prefer to see when I install it to sync their stuff. Given that they are even less technically inclined than myself it keeps it simple.


+1 for start on login. This is probably the behaviour most users expect, it adheres to KISS and doesn’t open any doors to possible security problems. Sounds like a winner to me.

One service for all users for me. I’m running Syncthing to move database backups and transaction logs from one server to another, and I want it starting automatically after a scheduled reboot at 3am when no one is logged in at all.

1 Like

Thanks for your comments!

@Ben_Curthoys in your case, how important would 1) an installer, 2) a GUI / tray icon be?

I’m going to move this to User Stories, as I think it fits better there.

I already wrote a user story for my use case: Infrastructure Syncing I also already wrote an installer that creates a Windows service: Don’t care about a tray icon =)

Turning a non-service application into a service is a mild pain in the arse, even if you know what you’re doing - enough that I wrote my installer because I felt that I needed it to distribute to my colleagues, and decided to contribute it second.

I think the default should be a startup shortcut, with install as a service as either an option in the installer or a separate installation file.

1 Like


I use “Start on Login” (normal link in autostart) because I only have one user and the user is automatically logged in so both cons you list are irrelevant for me.

:+1: I also think this is the best.

:+1: And this is some random text as it needs to be at least 20 characters long.

I think the best option is to allow a service install for server type scenarios where files should be syncing all the time, plus a per user install for syncing peoples personal files.

Casual users would use the per user option (which would be the default), while power users would probably prefer the service option.

1 Like

Looking at your responses, I think it makes sense to separate the use-cases of:

  • User who uses Syncthing to sync personal files. Wants a pretty GUI, doesn’t want to worry about security. Tray utility that starts on login suits well.
  • Sysadmin who uses Syncthing as part of their infrastructure. Wants a service, is smart / responsible enough to handle security implications. Single service setup suits well.

Not sure I’d try and bundle the two into one installer - GUI packages can get quite large (SyncTrayzor is ~40MB and bundles Chromium; syncthing-gtk would be ~13MB if it had a proper offline installer), plus you’re springing a surprising but critical decision on the user when they’re not expecting it, and just want to get something working.

EDIT: beat me to it by seconds!



It sounds like no-one’s really concerned about the ‘Syncing User A’s personal files while User B is logged on’ scenario?

FYI, related comment from the parallel UI thread:

It sounds like no-one’s really concerned about the ‘Syncing User A’s personal files while User B is logged on’ scenario?

If anyone wants that, I envision them simply installing as a service and using a shared configuration.

I personally think it should be one installation package with the option to install as a service.

The only use case I’ve used so far is for a company with circa. 18 devices, one device is a very powerful dedicated server hosted in a data centre, the others are mainly Windows 7/8.1 devices with 1 MacAir. I don’t want to have the trouble of installing for each user on each device.

1 Like

I’m heavily against services in a user context.

In our department we have about 10 machines, 4 of them are used by different people and need access to files that are best synchronized to local files. If two users decide to install their shares as service they will not only sync the same data twice (which is not the problem) but they will do it simultaneously, hidden behind services that might not be visible to the user itself, but only to machine administrators.

If a user log’s in, they are allowed to run whatever they want in their own context, but as soon as they log off, everything related to them needs to shut down or the machine might become unresponsive.

On the other side, if we want to host a server, one service is enough. Maybe a slimmer or CLI interface would help, but I do not see a scenario where multiple services would help in any way (except in SASS enviroment).

1 Like

Looks like the discussion’s turning from “Service or start-on-login” to “One installer for both service and per-user start-on-login, or two separate installers”?

This question is more nuanced. My personal worry is that starting Syncthing as a service has severe security implications, and so we should only let people who know what they’re doing, and who know for sure that what they need is a service (as opposed to “Oh, that looks neat” or “I dunno, maybe this one?”) install Syncthing as a service. I doubt whether presenting the two options side-by-side in the same installer achieves this. Other opinions welcome!

  1. As you pointed out, GUI packages can be quite large, which I think is reason enough to have separate installers
  2. The service doesn’t have to be installed as Local System.

The most effort / best thing to do would be to create a new user account for the service, and make the service run as that, and then make the user explicitly grant file access to those folders they want to sync… That’s well beyond what I can do in NSIS without taking weeks over it though =)

I still think the idea of a possible attack are very small, even if said malware got into the share to delete all files, the user would need to execute it first. Once that has been executed, surely it would have the privileges anyway or am I missing something?

Unless the user makes a share under system32 which would allow anyone with the same share to delete it anyway.

I don’t see how

Grants any merit, how will the malware be executed in the first place? Syncthing splitting it up into blocks sure wouldn’t do that it would be the USER executing the file opening the system up with THEIR privileges.

Am I wrong?

I get that a buffer overflow is another option but Golang isn’t affected by buffer overflow exploits so this whole discussion seems rather pointless. (slide 17)

Garbage Collected Go is also a safer language: Pointers but no pointer arithmetic No dangling pointers Variables are zero-initialized Array access is bounds-checked No buffer overflow exploits

The point is that if a user executes a malicious file, that file runs with the user’s permissions. It can only change things the user has permission to change.

But… If Syncthing is running as a local admin, and doesn’t have a GUI password set up, any process can talk to Syncthing. Even the most unprivileged process can open a connection on port 8080 and talk to its REST API. It can ask Syncthing to set up a folder anywhere (since Syncthing, running as local admin, has permission to do anything), and it can then ask Syncthing - very nicely, and without needing to overflow any buffers - to read or write any file in that folder.

There are several lines of defence against malware. The first line is the user - trusting your user not to download/run a file which looks legit but isn’t. Users, in general, are notoriously bad at doing this, especially the less computer literate. Browser vulnerabilities also let malicious people run processes on your computer without your consent.

We try and teach our users to behave here, but we don’t trust them to.

The next line of defence is user permissions. Since Vista, user accounts of been fairly unprivileged by default, with a UAC prompt required to elevate those permissions (Linux has taken this approach since the dawn of time). If I can get malware onto someone’s computer - and this happens all the time, you can’t argue that it isn’t a risk - then I can only run processes with the same privileges as that user. I can delete their files (cryptolocker), I can show adware all the time, but I can’t install a keylogger, disable the antivirus, make modifications to existing programs, or alter windows. Well, I can try, but they’ll get that pesky UAC prompt and know something’s up.

… or not. If I have a look around and see that Syncthing is running as a local admin, and without a GUI password, then, as disucussed, I can modify any file I like, anywhere I like. It doesn’t take a big imagination to figure out how I can use that to get a process running with local admin privileges.

At this point you’ve lost. I’ve got full admin control of your computer. I’ve disabled your anti-virus, and installed that keylogger. I’ve got your bank details.

If you’re trying to argue that you should give all of your users local admin privileges, there are plenty of articles out there explaining why this is a Very Bad Idea. Letting Syncthing run as a local admin, without a GUI password, is tantamount to the same.

1 Like

Not without the API key you can’t and Syncthing doesn’t allow you to add a share this way.