The telemetry service depends on this now. I had to move it into
invokeFunction and use accessor.get otherwise getLogger on the service
was undefined.
I also had to move some the extension management service because it
depends on the moved telemetry service. I moved a few other services as
well to better match VS Code (sharedProcessMain.ts).
I swapped some this.services.get with accessor.get since that seems to
be the correct method although for these other services either method
seems to work.
I removed this under the impression the default was to allow it anywhere
but that's not the case. Since the service worker was already registered
in my browser I never got the error during testing.
Also move our memory default to the beginning of NODE_OPTIONS so it can
be overidden. The version of the flag with dashes seems to be the more
correct one now so use that instead of underscores.
Related: #2113.
I think having them combined and relying on if statements was getting
confusing especially if we want to add additional messages with
different payloads (which will soon be the case).
Turns out that while Typescript can't infer the callback return type
from it, Typescript can do the opposite and infer it from the callback
return type.
Unfortunately we can't use node-mocks-http to test a express.Router
that has async routes. See https://github.com/howardabrams/node-mocks-http/issues/225
router will just return undefined if the executing handler is async and
so the test will have no way to wait for it to complete. Thus, we have
to use supertest which starts an actual HTTP server in the background
and uses a HTTP client to send requests.
This is mostly so we don't have to do any wacky patching but it also
makes it so we don't have to keep checking if the request is a web
socket request every time we add middleware.
This way the connection can be initiated by either side. It looks like
sometimes the initial message from the client is lost (it never makes it
into the onControlMessage callback) but I'm still not sure why or if
that is preventable.
Also added a timeout on the server end to clean things up in case the
client never responds.
Now we add a subject alt name, set extendedKeyUsage and use the
correct certificate extension.
The above allow it to be properly trusted by iOS.
See https://support.apple.com/en-us/HT210176
*.cert isn't a real extension for certificates, *.crt is correct
for it to be recognized by e.g. keychain or when importing as a profile
into iOS.
Updates #1566
I've been able to successfully connect from my iPad Pro now to my
code-server instance with a self signed certificate! Next commit
will be docs.
If do not update the UID within the passwd database to match whatever
uid the container is being ran as, then sudo will not work when renaming
the user to match $DOCKER_USER as it will complain about the current
user being non-existent.
Removing them just for peace of mind even though they seem to get
filtered out later. This line is meant to only add remote extensions
that aren't capable of running in the browser. If they are
browser-capable they don't need to run in our shimmed Node environment.
This makes the fetch work independently of the worker's origin which is
no longer the same as the main thread (the main problem is the inability
to send cookies without setting SameSite to None).
This matches with the html in the VS Code repo and also fixes a problem
with the worker which loads HTML using data: and then can't load any
scripts because 'self' doesn't work.
- The .js build files are no longer committed so they're gone.
- ParsedArgs and EnvironmentService are now NativeParsedArgs and
NativeEnvironmentService.
- Interface for environment service was moved.
- getPathFromAmdModule was deprecated.
Otherwise it outputs when trying to open a file in an existing instance
externally. Externally there isn't an environment variable to branch on
to skip this line so instead output it with the other info lines in the
child process.
- Immediately create ipcMain so it doesn't have to be a function which I
think feels cleaner.
- Move exit handling to a separate function to compensate (otherwise
the VS Code CLI for example won't be able to exit on its own).
- New isChild prop that is clearer than checking for parentPid (IMO).
- Skip all the checks that aren't necessary for the child process (like
--help, --version, etc).
- Since we check if we're the child in entry go ahead and move the
wrap code into entry as well since that's basically what it does.
- Use a single catch at the end of the entry.
- Split out the VS Code CLI and existing instance code into separate
functions.
We only want to use an old version for glibc which the centos:7
image takes care of.
The old version of git used in debian:8 was causing problems
with the uid/gid passthrough with no user in passwd.
We do not try renaming $HOME anymore as there is no good way
to do it.
We also only try to convert if the user hasn't been changed.
Finally I added usage to the docker docs in install.md
Closes#2056
VS Code has a short delay before writing storage (probably to queue up
rapid changes). In the web version of VS Code this happens on the client
which means if the page is reloaded before the delay expires the write
never happens.
Storage updates are already promises so this simply returns the promise
returned by the delayer so it won't resolve until the write actually
happens.
Fixes#2021.
Add initial support for opening files / folders in running code-server instance.
Current limitations:
- unable to open a file in a new window, only folders
- unable to use addMode feature
- others...
We need the handler to be recognized as a PWA but we can just let the
original offline browser message show instead of our own message.
See #1925 and #1979.
tsc doesn't check if the output exists when incremental is true.
i.e if I delete the out directory, but keep the tsbuildinfo and
try to rebuild, nothing happens cause it thinks everything is
up to date I guess...
With this change, yarn clean will now remove the tsbuildinfo correctly
so things work as expected.
Otherwise the build keeps failing for me as tsc won't compile anymore.
Not sure why things work on CI/for asher but I don't think this will
cause any additional issues.
It can still be used to check for updates but will not apply them.
For now also remove the update check loop in VS Code since it's
currently unused (update check is hardcoded off right now) and won't
work anyway since it also applies the update which now won't work. In
the future we should integrate the check into the browser update
service.
- Instead we now use CentOS 7 for the static build to guarantee
that we only depend on libc v2.17
- For macOS we now pull in a static node binary and bundle that instead.
This release fixes bugs introduced with the release of v3.3.0
- We've reverted to VS Code 1.45.1 due to bugs in 1.46 #1667
- Accessing code-server from a web browser on Windows has been fixed#1642
- Search in project has been fixed#1665
- The glibc requirement on static releases has been lowered to v2.19 #1656
Pass the user data dir to the browser environment service then derive
all the paths we can based off that path like the global storage path
which the vim extension uses to store history (otherwise it gets stored
in the working directory from when code-server was spawned).
Arguably the better solution is to use the userdata scheme but that
won't work because the vim extension ignores the VS Code API.
Fixes#1551.
See #1532 for more context.
- Errored JSON requests will get back the error in JSON instead of using
the status text. This seems better to me because it seems more correct
to utilize the response body over hijacking the status text. The
caller is expecting JSON anyway. Worst of all I never actually set the
status text like I thought I did so it wasn't working to begin with.
- Allow the update error to propagate for JSON update requests. It was
caught to show the error inline instead of an error page when using
the update page but for JSON requests it meant there was no error and
no error code so it looked like it succeeded.
- Make errors for failed requests to GitHub less incomprehensible.
Previously they would just be the code which is no context at all.
The raw value is now passed back to VS Code so it can do the parsing
with its own URI class rather than trying to parse using Node's url
module first since that has no guarantee of working the same way. It
also lets us keep the vscode-remote bit internal to VS Code.
Removed the logic that keeps trying paths until it finds a valid one
because it seems confusing to open a path and silently get some other
path instead of an error for the one you tried to open. Now it'll just
use exactly what you specified or fail trying.
Fixes#1488. The problem here was that url.parse was encoding the spaces
then the validation failed looking for a literal %20.
- Add type to HTTP options.
- Fix certificate message always saying it was generated.
- Dedent output not directly related to the HTTP server.
- Remove unnecessary comma.
In Google cloud shell the host header is 127.0.0.1:8080 instead of the
actual URL. This is what we write out to the HTML so VS Code can pick it
up. However cloud shell rewrites this string when found in the HTML
before serving it so it becomes https://8080-[...].appspot.com,
resulting in an extra unexpected https:// in the
URI (vscode-remote://https://8080[...]). The resulting malformed URI
causes the extension host to exit.
- Fixes#1471
- Fixes#1468
- Fixes#1440 (most likely).
This will make it work regardless of what the current URL happens to be.
Also move the telemetry setting into the options since we might as well
make use of it seeing as how we have to parse it for the base path
anyway.
By design the disable-telemetry flag does not affect extension
telemetry, only the setting does, so disabling the setting when the flag
is set should cause extensions to also stop sending telemetry.
Fixes#1116.
It still won't work behind a base path, but if you're using a reverse
proxy you can just redirect to HTTPS yourself. And should probably
handle TLS termination there too.
For sockets I just needed to add back the proxy call.
I temporarily removed this during the refactor so it needed to be added
back. This time I bundled it with the nbin loader code since it's all
related (will also make it easier to remove).
- Add VS Code icon
- Trim dashboard to just display dedicated VS Code section
- Version was getting unset during build
- Add back nbin shim which I temporarily took out earlier
- Update tests for log level env var changes
Might fix#1181, although not for the reasons I initially
thought (because the URLs are resolved from the manifest path, not the
path of the current page). This should ensure that the URLs used by the
manifest are always correct regardless of the manifest's path.
When using a query parameter without a scheme, the scheme defaults to
`file`. This results in the files in the explorer being technically
different from the file picker files because they are file:// instead of
vscode-remote://, causing the same file to open twice and causing
numerous issues.
Normally the file explorer wouldn't even load at all in this case but we
provide a file service for file:// URLs as a failsafe for certain files
that wouldn't load correctly in the past. These files load fine now
using the vscode-remote scheme, so I'm also removing that service.
Related: #1351.
Fixes#1294.
https://github.com/cdr/code-server/issues/1188
Fixes issue with permissions mounting in directories in the container. Folders are generated by root causing issues when the container user "coder" wants to create sub-folders. This fix solves it, at least on Crostini (ChromeOS)
Fixes issues with unexpected characters breaking things when setting the
cookie (like semicolons).
This change as-is does not affect the security of code-server
itself (we've just replaced the static password with a static hash) but
if we were to add a salt in the future it would let us invalidate keys
by rehashing with a new salt which could be handy.
If you visit /login/ instead of /login the cookie will be set at /login
instead of / which means the cookie can't be read at the root. It will
redirect to the login page which *can* read the cookie at /login and
redirect back resulting in an infinite loop.
The previous solution relied on setting the cookie at / (any invalid
value works) which then overrode the login page cookie since
parseCookies only kept a single value. So the login page would see the
same cookie the root was seeing and not redirect back. However, that
behavior depends on the cookies being in the right order which I'm not
sure is guaranteed.
This new method tests all available cookies and always sets the cookie
so the root path will be able to read it in case the login page is
seeing a cookie the root can't.
It also goes a step further and explicitly sets the path on the cookie
which fixes the case where there is a permanent misconfiguration
redirecting /login to /login/. Otherwise the cookie would continually be
set on /login only and you'd have another loop. It also means you only
need to delete one cookie to log out.
Lastly add some properties to make the cookies a bit more secure.
It doesn't show in the explorer anymore so there's no point. Also remove
the local scheme transform which is no longer required with the latest
client-side extension implementation.
Instead of doing a separate redundant build. The main problem was that
the files weren't being cached. There is probably a better way of
solving this but this seems to be the simplest for now.
This matches how the rest of the build is organized but also hopefully
solves an issue where the VS Code directory is empty because we try to
cache it directly and Travis might be creating it.
Also too the opportunity to rewrite the build script since there was a
change in the build steps (mainly how the product JSON is inserted) and
to get the build changes out of the patch. It also no longer relies on
external caching (we'll want to do this within CI instead).
- Copy old icon back into repository
- Update path to icon from manifest file
- Add link metadata tag for iOS PWA icon to workbench.html
- Add link metadata tag for iOS PWA icon to login page
* [README] add Requirements section
This is based user feedback and testing. This may expand if need be
Signed-off-by: Ayane Satomi <chinodesuuu@gmail.com>
* [README] raised the bar a bit more
Apparently we were targeting GLIBC 2.17
Signed-off-by: Ayane Satomi <chinodesuuu@gmail.com>
- Don't error if trying to tag and the tag already exists.
- Add the build arguments to the Docker build.
- Set an environment variable for the Docker build rather than using
- the username because the username always exists (on master anyway).
* made spacing for travis yaml consistent in file
* cleaned up .travis.yml and moved some code into a script
* checking if i can get travis to build this
* travis
* fixed an if statement
* fixed travis.yml file
* replaced my name with codercom
There's no way to actually know if those clients have gone away, so it
seems it might be better to base it on whether the user has connected
again with new clients to determine if the old clients are now invalid.
It gets the web URL for the file yet uses the file service to load it,
so having a sub-path causes it not to be found on disk (the sub-path
obviously only means anything for the web server and isn't on disk).
This removes the potential for a bad build because the native Node
modules currently can only be built on the target system, so specifying
a target for something other than the system your are building on will
not work.
- Implement the localization service.
- Use the proper build process which generates the require JSON files.
- Implement getting the locale and language configuration.
- Don't use "any" for the API type.
- Remove everything from the Coder API that can eventually be done
through the VS Code API.
- Move the event emission to our own client to minimize patching.
This means that you have to turn on features now instead of disabling
them like auth and https.
In addition:
- Allow multiple options for auth (only password for now).
- Combine the install docs since they had many commonalities and
- generally simplified them (hopefully not too much).
- Move all example configs into docs/examples.
When `isAuthed()` is called and the password cookie is not what we
expected, the failed login attempt is logged with the provided password,
remote address and user agent.
To allow for logging failed attempts with a reverse proxy, the
`--trust-proxy` argument has been added to trust the `X-Forwarded-For`
header. This implementation of an `X-Forwarded-For` parser uses the last
value in the list, therefore only trusting the nearest proxy.
I run code-server behind an authenticating Kubernetes Ingress which sets a cookie after a successful login is performed. Since this cookie is not set when fetching the manifest, the fetch fails and gets redirected to the authentication page, breaking code-server completely.
See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link
This is to match how the other binaries are built. Also made some
changes to make the Docker containers clean up for when you are running
this locally.
Since there is no other way to enable hidden files, it seems better to
enable it by default otherwise there are some folders/files you simply
can never open from the dialog.
* Set NODE_ENV and VERSION when building
Should fix the version flag not reporting correctly as well as enable
the service worker and prevent the 404 hmr requests again.
* Log env vars
To help make sure it's built correctly when looking at the Travis logs.
Since this will be a path in the binary that we don't want to create on
the user's system. I also removed the option to override it; it doesn't
seem like a great idea since you'd always want those builtin extensions.
This way we also don't have to check if the option was passed and only
create it if that was the case.
This isn't a real error event; we artificially emit it just in case
something waiting to start is listening to the error event in order to
clean up and/or restart.
* Allow setting paths for builtin exts and extra dirs
The extra directories aren't used yet, just available from the
environment service and to the shared process.
* Utilize extra builtin extensions path
* Utilize extra extensions directory
* Fix cached mtimes for extra extension dirs
* Simplify extension cache equality check
* Implement write/read buffers in electron fill
This makes cutting and copy files from the file tree work.
* Implement fs.createReadStream
This is used by the file tree to copy files.
* Allow passing proxies back from client to server
This makes things like piping streams possible.
* Synchronously bind to proxy events
This eliminates any chance whatsoever of missing events due to binding
too late.
* Make it possible to bind some events on demand
* Add some protocol documentation
* Let people know when telemetry is disabled, change url to https if secure connection
* Remove --no-auth as a http candidate
* Rename variable, change let to const
* Make all assets unique
All CSS and JavaScript files have unique names now. I also moved the
login to the /login path in order to ensure the HTML for each page is
also unique.
* Explicitly include assets to cache
* Added serviceworker and manifest.json
* added deps in package.json
* fixed image link
* actually fixed images i think
* added assets to individual module folders
* added caching
* Serviceworker now properly loads
* Changed single to double quotes
* Update lock
* moved the service worker back into prod only
* removed sw from general
* changed background color of splash screen
* added logo to server
* centralized logo into single assets folder
* Update Node to 10.15.1
* Remove string replace that was used for oclif
* Update nbin
* Package node-pty and spdlog with nbin
* Label stderr/stdout from shared process
* Remove fork override
* Prevent "already disposed" errors when trying to kill disposed proxies
* Include spdlog dependencies
* Shim /node_modules
* Add node_modules to Docker ignore
It keeps using my already-built .node files which results in a
mismatching GLIBC version error.
* Update nbin
* Allow use of the enter key for password input for code-server
* Remove function, make html form
* Remove function and create html form
* Handle form submit action
* Remove button listener
* Check if form exists
- "Open folder" now says "open folder" instead of "open file"
- "Open folder" won't allow you to open files
- "Open file" won't allow you to open directories
Fixes#249.
* Update VS Code to 1.33.0
* Fix slow file tree
* Fix WindowsService fill
* Provide `off` on event listeners
* Fix webview
* Fix double title bar and missing preferences on Mac
* Bump VS Code version in Travis config
* Fix black dialog text (again)
* Fix shared process not starting
- Adds dumb-init so closes#403, closes#361, closes#383
- User mode docker so closes#192, closes#65
- Uses latest docker ubuntu instead of 18.10 which is the rolling tag so closes#404
Thanks to @RichardMcSorley and @sr229
* Add clear error message if port is in use
* Add bold function for text/numbers
* remove unused dependency:
* remove unused line break
* Change logger message
* Use NodeJS.ErrnoException type
* Add back check for error code
* Adjust linux distro to ubuntu 14.04
* Cache lib directory for speedy builds
* Fix path linking for default extensions
* Update reset
* Reset to head
* Improve caching
* Still run yarn in CI
* Update yarn before install
* Increase cache timeout
* Install vscode from vstar
* Undo data-dir changes to CLI, add back clean, remove unused CI func
* Remove additional flags added
* Remove unused dependency
* Reset vscode install dir so patching always works
* Convert fully to protobuf (was partially JSON)
* Handle all floating promises
* Remove stringified proto from trace logging
It wasn't proving to be very useful.
Registering returns an instance that lets you retry and recover without
needing to keep passing the name everywhere.
Also refactored the shared process a little to make better use of the
retry and downgraded stderr messages to warnings because they aren't
critical.
tslint-language-service is the deprecated version which we don't
actually even have listed in the package.json. typescript-tslint-plugin
is the new version.
* Make proxies decide how to handle disconnects
* Connect to a new terminal instance on disconnect
* Use our retry for the watcher
* Specify method when proxy doesn't exist
* Don't error when closing/killing disconnected proxy
* Specify proxy ID when a method doesn't exist
* Use our retry for the searcher
Also dispose some things for the watcher because it doesn't seem that
was done properly.
The searcher also now starts immediately so there won't be lag when you
perform your first search.
* Use our retry for the extension host
* Emit error in parent proxy class
Reduces duplicate code. Not all items are "supposed" to have an error
event according to the original implementation we are filling, but there
is no reason why we can't emit our own events (and are already doing so
for the "disconnected" event anyway).
* Reconnect spdlog
* Add error message when shared process disconnects
* Pass method resolve to parse
* Don't pass method to getProxy
It doesn't tell you anything that trace logging wouldn't and has
no relation to what the function actually does.
* Fix infinite recursion when disposing protocol client in tests
* Add information about release notifications/gif
* Remove unecessary space
* Add smaller gif
* Add even smaller gif
* Trim time in new gif
* Cropped a tad more
* Fix weird aligning
* Set low CPU priority on watcher
Fixes#247.
* Batch stat and readdir calls
* Fix fs.exists
callbackify seems to always adds an error as the first argument. Opted
to just use the promise for this one.
* Batch lstat
* Add maximum time for flushing batches
* Replace evaluations with proxies and messages
* Return proxies synchronously
Otherwise events can be lost.
* Ensure events cannot be missed
* Refactor remaining fills
* Use more up-to-date version of util
For callbackify.
* Wait for dispose to come back before removing
This prevents issues with the "done" event not always being the last
event fired. For example a socket might close and then end, but only
if the caller called end.
* Remove old node-pty tests
* Fix emitting events twice on duplex streams
* Preserve environment when spawning processes
* Throw a better error if the proxy doesn't exist
* Remove rimraf dependency from ide
* Update net.Server.listening
* Use exit event instead of killed
Doesn't look like killed is even a thing.
* Add response timeout to server
* Fix trash
* Require node-pty & spdlog after they get unpackaged
This fixes an error when running in the binary.
* Fix errors in down emitter preventing reconnecting
* Fix disposing proxies when nothing listens to "error" event
* Refactor event tests to use jest.fn()
* Reject proxy call when disconnected
Otherwise it'll wait for the timeout which is a waste of time since we
already know the connection is dead.
* Use nbin for binary packaging
* Remove additional module requires
* Attempt to remove require for local bootstrap-fork
* Externalize fsevents
- It logs the error now.
- For some reason when there is an error node-netstat runs the callback
twice. That resulted in us scheduling an exponentially growing number
of calls which ate up all the CPU (and probably memory eventually).
For now, opted to dispose when there is an error.
* Fixed documentation based on latest release
* Fixed google-cloud documentation steps order
* Edited docs based on the latest release versions
* Make docs more dynamic based on Releases
* Changed ordered list to unordered list
Run [VS Code](https://github.com/Microsoft/vscode) on any machine anywhere and access it in the browser.
`code-server` is [VS Code](https://github.com/Microsoft/vscode) running on a remote server, accessible through the browser.

Try it out:
```bash
docker run -t -p 127.0.0.1:8443:8443 -v "${PWD}:/root/project" codercom/code-server --allow-http --no-auth
```
## Highlights
- Code on your Chromebook, tablet, and laptop with a consistent dev environment.
-If you have a Windows or Mac workstation, more easily develop for Linux.
-Take advantage of large cloud servers to speed up tests, compilations, downloads, and more.
- Preserve battery life when you're on the go.
- All intensive computation runs on your server.
- You're no longer running excess instances of Chrome.

- Code on any device with a consistent development environment
-Use cloud servers to speed up tests, compilations, downloads, and more
-Preserve battery life when you're on the go; all intensive tasks run on your server
## Getting Started
### Hosted
There are two ways to get started:
[Try `code-server` now](https://coder.com/signup) for free at coder.com.
1. Using the [install script](./install.sh), which automates most of the process. The script uses the system package manager (if possible)
2. Manually installing code-server; see [Installation](./doc/install.md) for instructions applicable to most use cases
### Docker
If you choose to use the install script, you can preview what occurs during the install process:
See docker oneliner mentioned above. Dockerfile is at [/Dockerfile](/Dockerfile).
```bash
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run
```
### Binaries
To install, run:
1. [Download a binary](https://github.com/codercom/code-server/releases) (Linux and OS X supported. Windows coming soon)
2. Start the binary with the project directory as the first argument
```bash
curl -fsSL https://code-server.dev/install.sh | sh
```
```
code-server <initial directory to open>
```
> You will be prompted to enter the password shown in the CLI
`code-server` should now be running at https://localhost:8443.
When done, the install script prints out instructions for running and starting code-server.
> code-server uses a self-signed SSL certificate that may prompt your browser to ask you some additional questions before you proceed. Please [read here](doc/self-hosted/index.md) for more information.
We also have an in-depth [setup and configuration](./doc/guide.md) guide.
For detailed instructions and troubleshooting, see the [self-hosted quick start guide](doc/self-hosted/index.md).
### Alpha Program 🐣
Quickstart guides for [Google Cloud](doc/admin/install/google_cloud.md), [AWS](doc/admin/install/aws.md), and [Digital Ocean](doc/admin/install/digitalocean.md).
We're working on a cloud platform that makes deploying and managing code-server easier.
Consider updating to the latest version and running code-server with our experimental flag `--link` if you don't want to worry about
How to [secure your setup](/doc/security/ssl.md).
- TLS
- Authentication
- Port Forwarding
## Development
```bash
$ code-server --link
Proxying code-server to Coder Cloud, you can access your IDE at https://valmar-jon.cdr.co
```
### Known Issues
## FAQ
- Creating custom VS Code extensions and debugging them doesn't work.
See [./doc/FAQ.md](./doc/FAQ.md).
### Future
## Want to help?
- Windows support.
- Electron and Chrome OS applications to bridge the gap between local<->remote.
- Run VS Code unit tests against our builds to ensure features work as expected.
See [CONTRIBUTING](./doc/CONTRIBUTING.md) for details.
## Contributing
## Hiring
Development guides are coming soon.
We ([@cdr](https://github.com/cdr)) are looking for engineers to help [maintain
code-server](https://jobs.lever.co/coder/e40becde-2cbd-4885-9029-e5c7b0a734b8), innovate on open source, and streamline dev workflows.
## License
Our main office is in Austin, Texas. Remote is ok as long as
you're in North America or Europe.
[MIT](LICENSE)
Please get in [touch](mailto:jobs@coder.com) with your resume/GitHub if interested.
## Enterprise
## For Organizations
Visit [our enterprise page](https://coder.com/enterprise) for more information about our enterprise offering.
## Commercialization
If you would like to commercialize code-server, please contact contact@coder.com.
Visit [our website](https://coder.com) for more information about remote development for your organization or enterprise.
1. Microsoft/vscode version 1.47.0 (https://github.com/Microsoft/vscode)
%% Microsoft/vscode NOTICES AND INFORMATION BEGIN HERE
=========================================
MIT License
Copyright (c) 2015 - present Microsoft Corporation
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This directory contains scripts used for code-server's continuous integration infrastructure.
Some of these scripts contain more detailed documentation and options
in header comments.
Any file or directory in this subdirectory should be documented here.
- [./ci/lib.sh](./lib.sh)
- Contains code duplicated across these scripts.
## Publishing a release
Make sure you have `$GITHUB_TOKEN` set and [hub](https://github.com/github/hub) installed.
1. Update the version of code-server and make a PR.
1. Update in `package.json`
2. Update in [./doc/install.md](../doc/install.md)
3. Update in [./ci/helm-chart/README.md](../ci/helm-chart/README.md)
- Remember to update the chart version as well on top of appVersion in `Chart.yaml`.
2. GitHub actions will generate the `npm-package`, `release-packages` and `release-images` artifacts.
1. You do not have to wait for these.
3. Run `yarn release:github-draft` to create a GitHub draft release from the template with
the updated version.
1. Summarize the major changes in the release notes and link to the relevant issues.
4. Wait for the artifacts in step 2 to build.
5. Run `yarn release:github-assets` to download the `release-packages` artifact.
- It will upload them to the draft release.
6. Run some basic sanity tests on one of the released packages.
- Especially make sure the terminal works fine.
7. Make sure the github release tag is the commit with the artifacts. This is a bug in
`hub` where uploading assets in step 5 will break the tag.
8. Publish the release and merge the PR.
1. CI will automatically grab the artifacts and then:
1. Publish the NPM package from `npm-package`.
2. Publish the Docker Hub image from `release-images`.
9. Update the AUR package.
- Instructions on updating the AUR package are at [cdr/code-server-aur](https://github.com/cdr/code-server-aur).
10. Wait for the npm package to be published.
11. Update the homebrew package.
- Send a pull request to [homebrew-core](https://github.com/Homebrew/homebrew-core) with the URL in the [formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/code-server.rb) updated.
## dev
This directory contains scripts used for the development of code-server.
- [./ci/dev/image](./dev/image)
- See [./doc/CONTRIBUTING.md](../doc/CONTRIBUTING.md) for docs on the development container.
- Have [nfpm](https://github.com/goreleaser/nfpm) (which is used to build `.deb` and `.rpm` packages and [jq](https://stedolan.github.io/jq/) (used to build code-server releases) installed
The [CI container](../ci/images/debian8/Dockerfile) is a useful reference for all
of the dependencies code-server uses.
## Development Workflow
```shell
yarn
yarn vscode
yarn watch
# Visit http://localhost:8080 once the build is completed.
```
To develop inside an isolated Docker container:
```shell
./ci/dev/image/run.sh yarn
./ci/dev/image/run.sh yarn vscode
./ci/dev/image/run.sh yarn watch
```
`yarn watch` will live reload changes to the source.
If you introduce changes to the patch and you've previously built, you
must (1) manually reset VS Code and (2) run `yarn vscode:patch`.
## Build
You can build using:
```shell
./ci/dev/image/run.sh ./ci/steps/release.sh
```
Run your build with:
```shell
cd release
yarn --production
# Runs the built JavaScript with Node.
node .
```
Build the release packages (make sure that you run `./ci/steps/release.sh` first):
This tutorial shows you how to deploy `code-server` on an EC2 AWS instance.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features. You can also try out the IDE on a container hosted [by Coder](http://coder.com/signup)
---
## Deploy to EC2
### Use the AWS wizard
- Click **Launch Instance** from your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home).
- Select the Ubuntu Server 16.04 LTS (HVM), SSD Volume Type (`ami-0f9cf087c1f27d9b1)` at this time of writing)
- Select an appropriate instance size (we recommend t2.medium/large, depending on team size and number of repositories/languages enabled), then **Next: Configure Instance Details**
- Select **Next: ...** until you get to the **Configure Security Group** page, then add the default **HTTP** rule (port range "80", source "0.0.0.0/0, ::/0")
> Rules with source of 0.0.0.0/0 allow all IP addresses to access your instance. We recommend setting [security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html?icmpid=docs_ec2_console) to allow access from known IP addresses only.
- Click **Launch**
- You will be prompted to create a key pair
> A key pair consists of a public key that AWS stores, and a private key file that you store. Together, they allow you to connect to your instance securely. For Windows AMIs, the private key file is required to obtain the password used to log into your instance. For Linux AMIs, the private key file allows you to securely SSH into your instance.
- From the dropdown choose "create a new pair", give the key pair a name
- Click **Download Key Pair**
> This is necessary before you proceed. A `.pem` file will be downloaded. make sure you store is in a safe location because it can't be retrieved once we move on.
- Finally, click **Launch Instances**
---
### SSH Into EC2 Instance
- First head to your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home) and choose instances from the left panel
- In the description of your EC2 instance copy the public DNS (iPv4) address using the copy to clipboard button
- Open a terminal on your computer and use the following command to SSH into your EC2 instance
```
ssh -i "path/to/your/keypair.pem" ubuntu@(paste the public DNS here)
- You should see a prompt for your EC2 instance like so<img src="../../assets/aws_ubuntu.png">
- At this point it is time to download the `code-server` binary. We will of course want the linux version. Make sure you copy the link for the latest linux version on our [releases page](https://github.com/codercom/code-server/releases)
- If you run into any permission errors, make the binary executable by running:
```
chmod +x code-server-linux
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
- Finally, run
```
sudo ./code-server-linux -p 80
```
- When you visit the public IP for your AWS instance, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
> The `-p 80` flag is necessary in order to make the IDE accessible from the public IP of your instance (also available from the description in the instances page.
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This tutorial shows you how to deploy `code-server` to a single node running on DigitalOcean.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features. You can also try out the IDE on a container hosted [by Coder](http://coder.com/signup)
---
## Use the "Create Droplets" wizard
[Open your DigitalOcean dashboard](https://cloud.digitalocean.com/droplets/new) to create a new droplet
- **Choose an image -** Select the **Distributions** tab and then choose Ubuntu
- **Choose a size -** We recommend at least 4GB RAM and 2 CPU, more depending on team size and number of repositories/languages enabled.
- Launch your instance
- Open a terminal on your computer and SSH into your instance
> example: ssh root@203.0.113.0
- Once in the SSH session, visit code-server [releases page](https://github.com/codercom/code-server/releases/) and copy the link to the download for the latest linux release
- In the shell run the below command with the URL from your clipboard
- If you run into any permission errors when attempting to run the binary:
```
chmod +x code-server-linux
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
- Finally start the code-server
```
sudo ./code-server-linux -p 80
```
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
- When you visit the public IP for your Digital Ocean instance, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This tutorial shows you how to deploy `code-server` to a single node running on Google Cloud.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features. You can also try out the IDE on a container hosted [by Coder](http://coder.com/signup)
---
## Deploy to Google Cloud VM
> Pre-requisite: Please [set up Google Cloud SDK](https://cloud.google.com/sdk/docs/) on your local machine
- [Open your Google Cloud console](https://console.cloud.google.com/compute/instances) to create a new VM instance and click **Create Instance**
- Choose an appropriate machine type (we recommend 2 vCPU and 7.5 GB RAM, more depending on team size and number of repositories/languages enabled)
- Choose Ubuntu 16.04 LTS as your boot disk
- Check the boxes for **Allow HTTP traffic** and **Allow HTTPS traffic** in the **Firewall** section
- Create your VM, and **take note** of it's public IP address.
- Copy the link to download the latest Linux binary from our [releases page](https://github.com/codercom/code-server/releases)
3. Make the binary executable if you run into any errors regarding permission:
```
chmod +x code-server-linux
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
4. Start the code-server
```
sudo ./code-server-linux -p 80
```
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
5. Access code-server from the public IP of your Google Cloud instance we noted earlier in your browser.
> example: 32.32.32.234
6. You will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
7. Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
7. We highly recommend switching the persistent disk to an SSD of at least 32 GB.
- Click `Change` under `Boot Disk` and change the type to `SSD Persistent Disk` and the size
to `32`.
- You can always grow your disk later.
8. Navigate to `Networking -> Network interfaces` and edit the existing interface
to use a static external IP.
- Click done to save network interface changes.
9. If you do not have a [project wide SSH key](https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#project-wide), navigate to `Security -> SSH Keys` and add your public key there.
10. Click create!
Remember, you can shutdown your server when not in use to lower costs.
We highly recommend learning to use the [`gcloud`](https://cloud.google.com/sdk/gcloud) cli
to avoid the slow dashboard.
## 2. Install code-server
We have a [script](../install.sh) to install `code-server` for Linux, macOS and FreeBSD.
It tries to use the system package manager if possible.
First run to print out the install process:
```bash
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run
```
Now to actually install:
```bash
curl -fsSL https://code-server.dev/install.sh | sh
```
The install script will print out how to run and start using `code-server`.
Docs on the install script, manual installation and docker image are at [./install.md](./install.md).
## 3. Expose code-server
**Never**, **ever** expose `code-server` directly to the internet without some form of authentication
and encryption as someone can completely takeover your machine with the terminal.
By default, `code-server` will enable password authentication which will require you to copy the
password from the`code-server`config file to login. It will listen on`localhost` to avoid exposing
itself to the world. This is fine for testing but will not work if you want to access `code-server`
from a different machine.
There are several approaches to securely operating and exposing `code-server`.
**tip**: You can list the full set of `code-server` options with `code-server --help`
### SSH forwarding
We highly recommend this approach for not requiring any additional setup, you just need an
SSH server on your remote machine. The downside is you won't be able to access `code-server`
on any machine without an SSH client like on iPad. If that's important to you, skip to [Let's Encrypt](#lets-encrypt).
First, ssh into your instance and edit your `code-server` config file to disable password authentication.
```bash
# Replaces "auth: password" with "auth: none" in the code-server config.
sed -i.bak 's/auth: password/auth: none/' ~/.config/code-server/config.yaml
```
Restart `code-server` with (assuming you followed the guide):
```bash
sudo systemctl restart code-server@$USER
```
Now forward local port 8080 to `127.0.0.1:8080` on the remote instance by running the following command on your local machine.
code-server has the ability to secure your connection between client and server using SSL/TSL certificates. By default, the server will start with an unencrypted connection. We recommend Self-signed TLS/SSL certificates for personal use of code-server or within an organization.
This guide will show you how to create a self-signed certificate and start code-server using your certificate/key.
## TLS / HTTPS
You can specify any location that you want to save the certificate and key. In this example, we will navigate to the root directory, create a folder called `certs` and cd into it.
```shell
mkdir ~/certs &&cd ~/certs
```
If you don't already have a TLS certificate and key, you can generate them with the command below. They will be placed in `~/certs`
You will be prompted to add some identifying information about your organization
```shell
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code)[AU]:US
State or Province Name (full name)[Some-State]:TX
Locality Name (eg, city)[]:Austin
Organization Name (eg, company)[Coder Technologies]:Coder
Organizational Unit Name (eg, section)[]:Docs
Common Name (e.g. server FQDN or YOUR name)[]:hostname.example.com
Email Address []:admin@example.com
```
>If you already have a TLS certificate and key, you can simply reference them in the `--cert` and `--cert-key` flags when launching code-server
## Starting code-server with certificate and key
1. At the end of the path to your binary, add the following flags followed by the path to your certificate and key like so. Then press enter to run code-server.
2. After that you will be running a secure code-server.
> You will know your connection is secure if the lines `WARN No certificate specified. This could be insecure. WARN Documentation on securing your setup: https://coder.com/docs` no longer appear.
## Other options
For larger organizations you may wish to rely on a Certificate Authority as opposed to a self-signed certificate. For more information on generating free and open certificates for your site, please check out EFF's [certbot](https://certbot.eff.org/). Certbot is a cli to generate certificates using [LetsEncrypt](https://letsencrypt.org/).
[code-server](https://coder.com) is used by developers at Azure, Google, Reddit, and more to give them access to VS Code in the browser.
## Quickstart guide
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This document pertains to Coder specific implementations of VS Code. For documentation on how to use VS Code itself, please refer to the official [documentation for VS Code](https://code.visualstudio.com/docs)
It takes just a few minutes to get your own self-hosted server running. If you've got a machine running macOS, Windows, or Linux, you're ready to start the binary which listens on port `8443` by default.
<!--
DO NOT CHANGE THIS TO A CODEBLOCK.
We want line breaks for readability, but backslashes to escape them do not work cross-platform.
This uses line breaks that are rendered but not copy-pasted to the clipboard.
-->
1. Visit [the releases](https://github.com/codercom/code-server/releases) page and download the latest cli for your operating system
2. Double click the executable to run in the current directory
3. Copy the password that appears in the cli<img src="../assets/cli.png">
4. In your browser navigate to `localhost:8443`
5. Paste the password from the cli into the login window<img src="../assets/server-password-modal.png">
> NOTE: Be careful with your password as sharing it will grant those users access to your server's file system
### Things to know
- When you visit the IP for your code-server, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../assets/chrome_confirm.png">
code-server can be ran with a number of arguments to customize your working directory, host, port, and SSL certificate.
```
USAGE
$ code-server [WORKDIR]
ARGUMENTS
WORKDIR [default: (directory to binary)] Specify working dir
OPTIONS
-d, --data-dir=data-dir
-h, --host=host [default: 0.0.0.0]
-o, --open Open in browser on startup
-p, --port=port [default: 8443] Port to bind on
-v, --version show CLI version
--allow-http
--cert=cert
--cert-key=cert-key
--help show CLI help
--no-auth
--password=password
```
### Data directory
Use `code-server -d (path/to/directory)` or `code-server --data-dir=(path/to/directory)`, excluding the parentheses to specify the root folder that VS Code will start in
### Host
By default, code-server will use `0.0.0.0` as its address. This can be changed by using `code-server -h` or `code-server --host=` followed by the address you want to use.
> Example: `code-server -h 127.0.0.1`
### Open
You can have the server automatically open the VS Code in your browser on startup by using the `code server -o` or `code-server --open` flags
### Port
By default, code-server will use `8443` as its port. This can be changed by using `code-server -p` or `code-server --port=` followed by the port you want to use.
> Example: `code-server -p 9000`
### Cert and Cert Key
To encrypt the traffic between the browser and server use `code-server --cert=` followed by the path to your `.cer` file. Additionally, you can use certificate keys with `code-server --cert-key` followed by the path to your `.key` file.
> Example (certificate and key): `code-server --cert /etc/letsencrypt/live/example.com/fullchain.cer --cert-key /etc/letsencrypt/live/example.com/fullchain.key`
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
### Nginx Reverse Proxy
Nginx is for reverse proxy. Here is a example virtual host that works with code-server. Please also pass --allow-http. You can also use certbot by EFF to get a ssl certificates for free.
```
server {
listen 80;
listen [::]:80;
server_name code.example.com code.example.org;
location / {
proxy_pass http://localhost:8443/;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;
}
}
```
### Help
Use `code-server -h` or `code-server --help` to view the usage for the cli. This is also shown at the beginning of this section.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.